Hi Scott :-)
Hi All,
Just musing: It’s very convenient in an Ndef to do something like this
Unfortunately the NdefGui doesn’t pick up the spec from this. Not sure if NamedControl should store any specs in the global spec dictionary (probably not?) or if the NodeProxy should pick up any local specs defined in NamedControls (probably yes as this would allow for local override of defined specs, which seems rather desirable?)
That is exactly why JITLibExtensions has addSpec for adding specs to all Xdefs:
Ndef(\x).addSpec(\coef, [-0.99, 0.99]);
What is the best logic for including implicitly added specs?
(as in:)
NodeProxy could have its own getSpec method;
if there is not an explicit spec yet,
look if there is one in NodeProxy.objects ... metadata,
and if yes, use that, else guess (as now).
This could become confusing when you rewrite the ndef source:
should it keep the last found one (which is now in ndefs specs),
or take the new one?
Not sure what the best precedence order would be here,
Scott, what are your ideas for this?
best a
BTW, I notice that the example under 'Comparison with direct use of Controls’ seems to be broken. The first case with NamedControl throws an error with 'NamedControl: cannot have more than one set of fixed lag values in the same control.’.
If I remove the lags it works but produces a synth with one control called freq. The second Control.names case produces a def with two controls called freq, only one of which can be set. I’m not sure what the desired behaviour is here (should NamedControl not post a warning?) but I think some it could be clarified what this is meant to demonstrate.
S.