Ndef as a fx chain: i'm stuck

23

Before I forget about this thread, I’m going to add a “table of contents” here for the several ways to skin this cat that have been discussed above. This will be a bit biased, I admit.

  1. If you only need to change the names of an already complied SynthDef, then you can do this quite safely by changing its .allControlNames, possibly using deepCopy too if you need several instances each with different control names. This is discussed in post #9 as makeSDclones. This techinque alone isn’t too useful for Ndef / NodeProxy roles (like \filer ->), but you can plug the resulting SynthDefs directly into NodeProxy sources slots.

  2. The previous technique can be adapted to NodeProxy roles by writing custom roles that essentially intercept the the ProxySynthDef object returned by .buildForProxy. This method has been discussed in post #20 under the names \mixM. \filterM, and \filterInM where a “mass generator” of such roles was given that can essentially take an existing role and add the automatic renaming functionality to it, producing a new role automagically.

The two related techniques above don’t require any extensions to the SC class library.

  1. If you need to combine several functions that produce SynthDef code into one SynthDef that doesn’t have control name conflicts, then the most general method is to install a mangler that intercepts the ControlNames as they get emitted to the SynthDef graph as it is being compiled. While this method does require some SC extensions, it does buy you the ability to SynthDef.wrap the same function multiple times in the same SynthDef e.g. with suffixed argument names for each invocation. Extension code for this method has been provided in post #13. To emphasize again: in difference to the technique used at the previous two points, this one produces a single resulting SynthDef, possibly from many instances of the same synth function. Although (in hindsight) a bit overkill for NodeProxy roles, this technique can also be used for them, as shown (as another application, if you will) in the 2nd part of post #14 as \mixN and \filterN. (Not much creativity with names, I admit.)

  2. Related to technique 3, you can also mangle the names in the function text code, but this approach is a little more brittle, because it might not find the control names to replace if they don’t show up in the function text directly, because e.g. they are obtained by calling yet another function. This technique has been discussed in post #2.

  3. If you’re willing to restrict yourself to using NamedControls invoked in \sym.kr style, a technique requiring simpler extensions is to alter / extend those Symbol methods a bit to do the mangling, e.g. to lookup some suffix from an environment and use inEnvir to evaluate the function in the right environment to get the suffix. This has been discussed in posts #10 and #12. A variation on this that essentially turns your SynthDef function in a macro of sorts, is to write ~foo.kr instead of \foo.kr and again to use inEnvir style evaluation for the replacement. The last approach requires no extensions whatsoever, but it does require one to change their source code.

I think I didn’t miss any major ideas / approaches discussed above in this summary. If I did, I apologize in advance. And please let me know if that’s the case so I can include the missing bits in this summary (while I can still edit it, that is).

2 Likes