The most direct and fast way to send commands to the server is to send messages to the Server object, if you are within sc-lang. If you are in a shell you can use sendOSC (available from CNMAT).
this messaging scheme is explained in detail in:
When creating nodes on the server (synths and groups) the only things we need to know are the nodeID and the server (its address to be precise).
In order to communicate with a synth, one sends messages with its nodeID. If you do not intend to communicate with the node after its creation (and the node will cause itself to end without external messaging), the node id can be set to -1, which is the server's equivalent to nil.
As soon as you want to pass around the reference to a certain node, assuming that you might not have only one server, it can be useful to create a Synth or Group object. These objects also respond to messages, and when needed can be used to obtain the state of the server side node.
see Node, Synth, and Group help for more detailed helpfiles on node objects.
the equivalent of
is
when passing arguments:
it is
note that Symbols may be used instead of Strings:
and:
The answer to the question of whether one should work with node objects or directly with messages depends to some extent on context, and to some extent is a matter of personal taste.
The encapsulation of node objects results in a certain generalization, meaning that other compound objects can respond to the same messages and thus exploit polymorphism. They also provide a certain level of convenience, keeping track of indexes and IDs, etc.
In certain cases, such as for granular synthesis it is recommended to use messages directly, because there is no benefit to be gained from the node objects (i.e. no need to message them) and they add cpu load to the client side.
In cases where you need to keep track of the synth's state, it is advisable to use node objects and register them with a NodeWatcher. (see helpfile)
Apart from such cases it is a matter of taste whether you want to use the combination of message and a numerical global representation or an object representation. The two can be mixed, and certain advantages of the object style can be accessed when using messaging style. For instance Server.nextNodeID allows one to use dynamically assigned IDs in messaging style. As a gross generalization, it is probably fair to say that object style is more convenient, but messaging style is more efficient, due to reduce client-side CPU load.
Note that Function-play and SynthDef-play return a synth object that can be used to send messages to.
Several node messages accept lists of values to map onto the controls of Synth nodes, as in some of the examples already given:
Argument lists generally appear as alternating pairs, with the control identifier preceding the value. Usually the control identifier is a name, as above, but it could also be an integer index. (Using integers is slightly faster for the server, but it makes the code harder to read and can introduce bugs if the SynthDef structure changes.) One way to find out control indices is to .add the SynthDef into a SynthDescLib, then get the list of all controls out of the SynthDesc.
Prints:
The list shows that the 'freq' control has index 0, 'amp' is 1 and so on. Detune is defined as an "array argument," occupying indices 2-3.
SynthDefs with a large number of controls may need a little extra code to print the entire list.
Prior to SuperCollider 3.3, the only way to set array arguments by name was using n_setn (or Node's setn method). Beginning in version 3.3, array arguments can be included in s_new or n_set messages transparently.
note the characters $[ and $] delimiting the array in the list:
the Node object automatically inserts $[ and $] for you:
Supplying an array for an argument in an event already has another meaning: multichannel expansion, in which a separate node is created for each array item. If all items of the array should be sent to the same node, then the array argument should be enclosed in another array level: