About Ndef:
AFAIK you can manually move a NodeProxy’s group into another group:
~pargroup = ParGroup(s);
Ndef(\a, { Silent.ar(1) });
Ndef(\a).group.moveToHead(~pargroup);
But…
NodeProxies use InFeedback.
I was a little suspicious about this for parallel processing. As I recalled, InFeedback’s result depends on the order of execution:
-
If the source node for the bus finished processing before the server reaches InFeedback, then InFeedback will output the block of audio being processed now.
-
If the source node comes after the node containing InFeedback, then it will output the previous block of audio.
In both cases, these are the most recently available audio blocks. But, if the order of evaluation is not consistent, then the output may not be consistent.
Let’s test that:
b = Bus.audio(s, 1);
a = { SinOsc.ar(200, 0, 0.1) }.play(outbus: b);
c = { InFeedback.ar(b, 1).dup }.play(target: a, addAction: \addAfter);
(
fork {
var order = Pseq([\moveBefore, \moveAfter], inf).asStream;
loop {
c.perform(order.next, a);
1.0.wait;
}
}
)
Oops.
This means you can’t randomly throw Ndefs into ParGroups. If one Ndef reads a signal from another, then you have to make sure that the target Ndef comes later in a serial (regular) Group. (Correctness of the result should be more important than “optimal” usage of multiple cores.)
If you don’t, and if supernova happens to put the source and target Ndefs onto separate cores at roughly the same time, then the target might evaluate InFeedback either before or after the source finishes, and there’s no guarantee of this being consistent. So you might get clicks.
hjh