In this example, the pattern will return an error every time it releases the synth because the Synth has already freed himself:
FAILURE IN SERVER /n_set Node 1060 not found
(
SynthDef(\beep, { |out, gate = 1, freq = 440, time = 0.1, amp = 0.1|
var sig = SinOsc.ar(freq);
var eg = EnvGen.ar(Env.perc(0.01, time), doneAction: 2);
Out.ar(out, (sig * amp * eg).dup);
}).add;
)
x=Pbind(\instrument,\beep,\dur,3,\freq,Pn(440,4)).play;
I don’t like having sets playing with errors, even “acceptable” ones.
So, is there a way to get rid of this error ?
In this simple example, one could just remove the doneAction but in more complex examples this doneAction can remain useful: the Synth can free himself automatically or after a gate. So this removing the doneAction is (in my opnion) not an option.
Best: Env.perc ignores gate – so you can simply delete gate from the argument list.
Oh I see – that’s my code and I had neglected to delete it! I’ll go back and edit the example in the other thread. I think this happened because I have a SynthDef snippet that includes gate = 1 and I wasn’t paying attention to that.
I used as a basic copy/paste.
If we go to more complex example.
Let’s say we have a Synth basically composed of a PlayBuf and a EnvGate. Both with their own doneAction. Because one’d like to free the Synth whatever comes first: the “natural” end of the Synth (ie the PkayBuf reached the end of the buffer) or the gate from the EventStreamPlayer.
In the cases where the “natural” end comes first, the EventStreamPlayer will throw an error because the synth has already been released.
I’d like to get rid of that error.
Even if you use the node’s /n_end notification to detect that it’s no longer necessary to send the release message, it’s still possible for the outgoing release message and the incoming notification to cross in transit, so node tracking is not 100% reliable to prevent the errors from being posted. (I know this from my Voicer class.) The only way to be sure is to tell the server not to post the error for the release message.
Isn’t it dangerous to hack system classes ? In this case we are just dealing with a non critical modification (hiding some error message), so no big issue. But in general, I’ll see the risk of loosing those modifications when upgrading to a new version of SC. And also the lack of “portability” of code relying on such hacks.
How are you dealing with those risks ?
Hmm, in this specific case, you could use startup.scd to overwrite the event type function. That would survive upgrades (though, if the function changes in some future version, you would invisibly overwrite that too). Event.addEventType can overwrite existing types, not just add new ones.
But…
To be honest, I would consider that to be possibly incorrect usage. If there’s a gate, then the default event prototype expects to be able to use the gate to release the synth. The synth case you’re suggesting is incompatible with that assumption. (It’s also possibly a problem for the audio too – if the buffer doesn’t fade out at the end, and the synth stops at buffer’s end, then click.)
It might be a valid feature request, to add a flag to the \note event type to silence the release error. I wouldn’t suggest that by default though, since the error could just as easily be a sign of a real bug in the user’s synth.