Synths run in the order given by the tree. A node can read the state of the buses as they are when the node is run using the In ugen. A node can change the state of the buses using the output unit generators as follows:
- Out - add (+) my output to the current contents of a bus
- ReplaceOut - replace the contents of a bus with my output
- XOut - crossfade between the current contents of a bus and my output.
- OffsetOut - like Out but offsets my output by a partial buffer to simulate sample accurate start time.
When the first node runs, the input audio buses will have the hardware input signal on them and all other audio buses will be zero.
Now this is the potentially confusing part, but I think it works as one would like: Control buses are left in the state they were in when last touched, they are not newly zero each cycle. Out.kr mixes values from the same output cycle, but will replace stale values (those values remaining on the bus from previous cycles). The difference between handling audio and control buses is actually in the In unit generator. In.ar will read zero if an audio bus contains stale values, but In.kr will read a stale value as the current value. This allows you to run a node that writes an envelope to a control bus and once that node is deallocated, its final value remains on the bus until something else replaces it.
(James McCartney)
- all nodes on a server can be represented by a linked list where it is possible to insert a node at any place.
- a node can read from and output to several busses.
- if a node reads and writes to different busses, the placement in the execution order can restrict the possibility for other nodes that rely on its output or are responsible for its input.
- this means that in order to create a node that can be deliberately patched to any other nodes without any further assumptions it should output its data solely to a number of reserved/private busses.
some points by Mark Ballora:
- There is one linked list of nodes from the root ID node (0).
- Nodes may be arranged by using an addAction or the ".head" or ".tail" messages. If not placed explicitly, new nodes will by default become the tail.
- The nodes may be Groups, Synths, or special ugen configurations (such as a combination of In.ar -> Out.ar to grab audio from a bus and play it.
- Group node have their own linked lists of nodes attached to them.
- Synth nodes are always terminal nodes.
- Nodes are executed sequentially, from head to tail. When a group node is reached, all of its subnodes are evaluated before the next node of the root list is evaluated.
- Execution of nodes is related to, but not exactly the same thing as, signal processing order.
These points are illustrated in the pdf file linked below. It is an illustration of some code contained in the Help file "Order-of-execution.help.rtf". It shows how Synths, Environment variables, linked lists and busses fit together.
order-of-execution.pdf
- the last content on a bus is kept until it is overwritten, that means a node can read off a bus that is being written onto by a node that is processed after. ( for audio busses this works only with the InFeedback ugen)
- when linking the output of node A to another bus, it is important to notice that:
- (case 1) the linking node L must come after A, but before any further node B on that bus that is supposed to use the output of A
- (case 2) or: on all busses that A uses there must be no other nodes (X,Y) that overwrite its data
case 1
case 2(this works only with the InFeedback ugen for audio rate, for control rate it is how the In ugen works)
this shows where a new node is created relative to a target node, dependant on the add actions
Note that there is addAction 4 now, which means free and replace the target node.
jrh
image data to build these graphics in photoshop: sc-bus-system.psd
(tip: alt-drag copies a layer, with ps6 or 7 you can check 'autoselect layer' on the drag tool to make it more fun)
.
