internal structure of the node proxy, node order and the parameter context
A NodeProxy has two internal contexts in which the objects are inserted: The group, which is on the server, and the nodeMap, which is a client side parameter context. As the group can contain an order of synths, there is a client side representation, in which the source objects are stored (see Order).
One node proxy can hold several objects in an execution order. The index can be any positive integer.
there are a couple of messages a NodeProxy understands that are related to play, stop etc. Here is what they do.
this pair of messages is related to the monitoring function of the proxy. play starts monitoring, stop ends the monitoring. if the proxy group is playing (this can be tested with .isPlaying), play will not affect the proxie's internal behaviour in any way. Only if it is not playing (e.g because one has freed the group by cmd-period) it starts the synths/objects in the proxy. Stop never affects the internal state of the proxy.
You can pass a vol argument to play to adjust the monitor volume without affecting the proxy internal bus volume.
this pair of messages controls the synths within the proxy. It does not affect the monitoring (see above). send starts a new synth, release releases the synth. send by default releases the last synth. if the synth frees itself (doneAction 2) spawn can be used.
in order to free the synths and the group together, free is used:
in order to free the synths and the group, stop playback, end is used.
in order to rebuild the synthdef on the server, use rebuild. this is of course far less efficient than send, but it can make sense; e.g. the synthdef has random elements. UGens like Rand(300, 400) create new random values on every send, while client-side random functions like exprand(1, 1.3) only get built once; to force new decisions with these, one can use rebuild.
when paused, a node proxy still stays active, but every synth that is started is paused until the proxy is resumed again.
Note that pause/resume causes clicks with audio rate proxies, which do not happen when pauseing control rate proxies.
clear removes all synths, the group, the monitor and releases the bus number.
note that when other processes use the nodeproxy these are not notified. So clearing has to be done with regard to this.
what happens to function arguments?
now the argument 'freq' is a control in the synth (just like in SynthDef) which you can change by the 'set' message.
the message xset is a variant of set, to crossfade the change using the current fadeTime:
the parameter context also can keep bus mappings. a control can be mapped to any control proxy :
the message xmap is a variant of map, to crossfade the change using the current fadeTime:
to remove a setting or a mapping, use unmap / unset.
also multichannel controls can be mapped to a multichannel proxy using map :
the parameter context can be examined: