There are a few problems happening - this is a case that JITlib does NOT handle well.
Here’s the graph just after I’ve set my three Ndefs, but before any mapping:
Everything looks okay, though we can already see one problem brewing:
\a
and
\b
are running AFTER
\sound
.
Here’s the graph after mapping Ndef(\a)
to in1
:
The problem from before has hit us:
\a
is running after
\sound
in the graph - so we’re reading from our bus before we’ve written any sound to it.
It gets worse… This is the graph after re-setting both of our ins (e.g. setting them a second time). Now, we somehow have some brand new 2-channel control buses mapped to our inputs… But, our corresponding synths are still playing out to their old audio buses.
This bug is pretty deep in JITlib / bus mapping code. You can easily see the side-effects, but I don’t know the exact cause… For example, before I map any buses, I have:
> Ndef(\sound).controlNames[0].dump;
Instance of ControlName { (0x7fecd1d40dc8, gc=6C, fmt=00, flg=00, set=03)
instance variables [6]
name : Symbol 'in1'
index : Integer 0
rate : Symbol 'audio'
defaultValue : instance of Array (0x7fecc36140a8, size=2, set=2)
argNum : Integer 0
lag : Float 0.000000 00000000 00000000
}
Looks correct: a two-channel audio-rate input. But after I map:
> Ndef(\sound) <<>.in1 Ndef(\a);
> Ndef(\sound).controlNames[0].dump;
Instance of ControlName { (0x7fec92528788, gc=F8, fmt=00, flg=00, set=03)
instance variables [6]
name : Symbol 'in1'
index : nil
rate : Symbol 'control'
defaultValue : instance of Array (0x7fecb1c6c7c8, size=2, set=2)
argNum : nil
lag : Float 0.000000 00000000 00000000
}
IIRC this part of the bug is triggered by \elastic
reshaping: if you skip elastic, you won’t get this audio / control rate mix-up. However, the node ordering problem still remains - and this part is not easy to solve, there is no declarative, guaranteed way to set the node order of NodeProxy
's, so this audio input mapping use-case is effectively broken without putting in some hacks yourself…
If you want this use-case to work, you can use Ndef:orderNodes
to set the node order AFTER you’ve done all your mapping.
You’ll need do this after you’ve started all your Ndef
s, and you’ll need to explicitly set the node order yourself - though it should be possible to visit all running Ndef
s, figure out the dependency graph based on their inputs, and then programmatically determine the right node order?
I gave up on this workflow in the end, because it was too prone to random breakages and unpredictable node ordering.