Re:Csound: A sound and music computing system
by jancsika on Sunday April 05, 2020 @11:29PM
(#22790693)
> flowing streams of high frequency audio over wires whose samples are at a much higher rate than the frame rate of the visual program's control signals
Pd's "control" classes are probably confusing to programmers coming from other computer music environments. There's no control rate in Pd.
The "control" classes (the ones without a tilde at the end of their name) send messages in zero logical time and may be triggered sporadically. Building diagrams out of them is like building an immediate-mode Rube Goldberg machine.
There are some conversion classes that allow control <-> signal object communication. Some of the control-to-signal classes do conversion at what you could call "control rate"-- e.g., they might compute a single value and copy it to the rest of the samples for output. Others do sub-sample accuracy bounded by the precision of floats (single or double as Pd can be compiled to use either).
If you're weird you can use [bang~] to emulate a control rate diagram-- it will literally output the "bang" message at each block which you can then feed to a downstream Rube Goldberg machine in order to do arbitrary message passing each block. But that's less ergonomic than just using signal objects which a) all send the same type of vector data and b) get automatically ordered by the graph builder and are therefore easier to read. (The irony being that signal diagrams generally deal with DSP, so the readable part of the diagram is the most conceptually complex and the simple stuff like branching or counting to 10 tends to end up looking like a plate of spaghetti.)
There's also overhead in the control message dispatch which would probably undo any imagined efficiency gains. Signal diagrams on the other hand get sorted into an array of function callbacks (as needed during runtime or editing time), so there's no chasing of pointers or type-checking to eat up cycles.
Pd's "control" classes are probably confusing to programmers coming from other computer music environments. There's no control rate in Pd.
The "control" classes (the ones without a tilde at the end of their name) send messages in zero logical time and may be triggered sporadically. Building diagrams out of them is like building an immediate-mode Rube Goldberg machine.
There are some conversion classes that allow control <-> signal object communication. Some of the control-to-signal classes do conversion at what you could call "control rate"-- e.g., they might compute a single value and copy it to the rest of the samples for output. Others do sub-sample accuracy bounded by the precision of floats (single or double as Pd can be compiled to use either).
If you're weird you can use [bang~] to emulate a control rate diagram-- it will literally output the "bang" message at each block which you can then feed to a downstream Rube Goldberg machine in order to do arbitrary message passing each block. But that's less ergonomic than just using signal objects which a) all send the same type of vector data and b) get automatically ordered by the graph builder and are therefore easier to read. (The irony being that signal diagrams generally deal with DSP, so the readable part of the diagram is the most conceptually complex and the simple stuff like branching or counting to 10 tends to end up looking like a plate of spaghetti.)
There's also overhead in the control message dispatch which would probably undo any imagined efficiency gains. Signal diagrams on the other hand get sorted into an array of function callbacks (as needed during runtime or editing time), so there's no chasing of pointers or type-checking to eat up cycles.