The simplest synthesis processes use a single ugen.
or
Most of the SuperCollider help documents for the UGens show other such examples.
////////////////////////////////////////////////////////////////////////////////////////////////////
Many synthesis processes, because they use more than a few ugens, are often best divided into component parts. This can make code modular, reusable, and easier to read.
The Group class, which is the means to specify a collection of nodes, provides a mechanism through which to control several synths at once.
The important technical feature of groups is that the nodes they contain are items in a linked list. A linked list is a data structure that makes it easy to order and reorder nodes. The first item in a linked list is the "head" and the last item is the "tail."
Groups, through their head and tail mechanisms, allow synths to be placed in order so one synth verifiably executes before another, eg, the head synth runs before the tail synth. The ability to order synths is essential when sending source audio through an effect, such as a reverb or a filter.
Another feature of groups is they allow synths to receive messages from a single point of control, eg, one message to the group goes to all of nodes that belong to the group.
See the Server Architecture document for a definition of a node in SuperCollider or look to the Wikipedia for a general discussion of nodes, linked lists, and trees.
By default, the localhost and internal servers each boot with two predefined groups: the RootNode and the Default Group (see their help files). To see this, start the localhost server and then evaluate
The next two lines
will appear in the transcript window.
Group(0) is the rootnode group and Group(1) is the default_group. Group(1) is indented to show that it branches from Group(0).
////////////////////////////////////////////////////////////////////////////////////////////////////
New synths are attached by default to the head of the default_group.
will appear in the transcript window. It shows Group(0) as the rootnode, Group(1) as the branching default_node and Synth 1003 (or some such number) as a leaf attached to the default_node.
////////////////////////////////////////////////////////////////////////////////////////////////////
An example with two synths.
The printout in the transcript window
shows that Group(0) is the rootnode and Group(1) is the default_node.
Synth 1005 and 1004 (or similar such numbers) are leaves attached to the default_node. Synth 1005 is first in the list because of the way nodes are attached, by default, to the head of a list: Synth 1004, the "ringModulation" synth, was evaluated first and attached to the head of Group(1). Then Synth 1005, the "pitchFromNoise"s synth, was evaluated and placed at the head of the list (in front of Synth 1004).
////////////////////////////////////////////////////////////////////////////////////////////////////
It's the responsibility of the user to make sure that nodes on the server are ordered properly. For this reason, the two synths below must be evaluated in the order in which they're given - because the first synth is source material for the second synth, a filter that processes its input.
////////////////////////////////////////////////////////////////////////////////////////////////////
Or, use .head and .tail messages to attach the nodes to the default_group).
////////////////////////////////////////////////////////////////////////////////////////////////////
Or, assign the synths to groups.
The idea is that the groups are attached first to the default_group in the desired order. The synths can then be evaluated in any order as long as they're attached to the appropriate group.
////////////////////////////////////////////////////////////////////////////////////////////////////
Set a control for all of the synths in a group.
////////////////////////////////////////////////////////////////////////////////////////////////////
go to 16_Playbuf