Can the server send s_new messages to itself?

Questions
21

I’m afraid I don’t have time to retest that at the moment.

But, retriggering an envelope and unpausing a node are two separate, distinct operations. So my comment about envelopes says nothing about what Pause.kr can or can’t do.

I would expect that Pause.kr, within a running node, could un-pause any paused node that has a different ID, no matter by which mechanism it was paused. (A possible gotcha here is, if you try to unpause using Pause.kr, but the target node re-pauses by PauseSelfWhenDone. Situations like this are probably why pretty much everyone frees nodes rather than pausing them.)

Retriggering an envelope means to set the gate input of an EnvGen to a positive value. If the node containing the EnvGen is paused, then the EnvGen will not detect the new gate value, and nothing will happen. It would be necessary to unpause the node before retriggering.

hjh

22

I’ve made something work. At least using a fixed envelope, which makes the logic simpler. The trick is to use a local bus to prepare a self-retrigger, just before pausing oneself, so that when it’s unpaused again it can actually go

(SynthDef(\brr, {
	var trig = LocalIn.kr(1, 1);
	var env = EnvGen.kr(Env.linen(), trig);
	var done = Done.kr(env);
	LocalOut.kr(done);
	PauseSelf.kr(done);
	Out.ar(0, env * SinOsc.ar());
}).add)

(b = s.makeBundle(false) {
	x = Synth.newPaused(\brr);
	NodeWatcher.register(x);
};

s.listSendBundle(nil, b);
)

x.run // OK!
x.run // after it's done it's paused but rearmed and goes again

As for

I think that for that one could abuse a buffer again to send, in a rather cryptic format, i.e. one sample = one control param. and then read them from fixed positions in that buffer. I’ll try something like that later. I can already forsee it would make for rather cryptic synths though!

23

Asynchronous commands on the Server are executed in 5 stages:

  1. RT thread: parse command arguments, allocate command data and start sequenced command
  2. NRT thread: perform non-realtime-safe operation (e.g. reading a soundfile) and store result in command data
  3. RT thread: do something with the result, e.g. swap buffers; also execute completion msg (if provided)
  4. NRT thread: non-realtime-safe clean up, e.g. delete old sound data; also send done message to client (if provided)
  5. RT thread: deallocate command data

If you want to know how it works in detail, you have to read the source code (server/scsynth/SC_SequencedCommand.cpp)

1 Like