Drnkhobo wrote:Can you elaborate there for me?
With a bi-quad, you usually see something like this somewhere in the code...
...basically a very short delay line, so that 'out1' and 'out2' are the previous sample, and the one before that.
If you changed the command order...
...it's now broken, because in2 and in1 end up with the same value.
In code, that's really easy to see - the commands are just a list that goes from top to bottom.
But with primitives, if a single output is linked to more than one input, the order that you make the links decides which way around the following primitives get executed. (seen as the little "ticks" at the end of the links).
When you have feedback, this gets much more critical - do it in the wrong order, and you can easily end up with an extra sample of delay where you didn't intend to, which will throw out the frequency response.
Drnkhobo wrote:Why no poly / dsp / asm double connectors?
You will have seen the 'mono4' streams, where four channels get processed as if they were all one.
Within the CPU, this uses special SSE commands that allow four of any operation to happen at the same time - a primitive form of 'parallel processing' that hugely reduces CPU load. In SSE, all variables are really 128bits wide - four 32bit floats combined.
Poly uses it to process voices in batches of four, so four notes uses the same CPU as only one.
And with DSP code and ASM, you might have noticed that a lot of modules have the 'black' connectors that automatically change to the correct type - this is only possible because '4-way' code is used even for mono (with 3 unused 'channels'). This allows exactly the same code to be used for all of the normal streams most of the time, which is very handy indeed!
The 'double' streams are an exception to the rule - you can't fit four of them into the same size as four singles, making them incompatible with the code for all the other types. Hence you need the special primitives to convert between the two.