A question I’ve been thinking about:
- It would be nice to have way more than six outputs.
- It would be nice to process polyphonic cables.
I’ve been thinking that just optionally treating INn and OUTn as arrays (e.g., OUT1[2] = foo) would be a pretty obvious way to do that. However, this brings up a performance vs obviousness problem.
Note well: this code below relies on imaginary syntax that DOES NOT EXIST (yet).
To explain:
Example 1
' Lower all values by 1.
FOR i = 1 to channels(IN1)
OUT1[i] = IN1[i] - 1
NEXT
Here’s the thing; each time NEXT is executed, there is a hidden WAIT 0 being executed, meaning that each assignment to OUT1 actually occurs one sample after the previous one. The implicit WAIT 0 is there to make it harder for the naive user to make a long loop that absolutely destroys the responsiveness of Rack. But the time smear on processing inputs/outputs is also pretty unexpected.
OK, so I thought, maybe a version of NEXT that says, hey, I know what the default behavior is, and I’m deliberately overriding it:
Example 2
' Lower all values by 1.
FOR i = 1 to channels(IN1)
OUT1[i] = IN1[i] - 1
NEXTNOWAIT
NEXTNOWAIT would not have the implicit WAIT 0, so BASICally would go through all the channels in IN1 in one clock cycle. It’s closer to what you’d expect, except it risks making Rack sputter, stall, and lose sonic cohesion.
I haven’t yet tried this in practice (I have an update to Venn that I’d like to wrap up before opening a new branch), so maybe it’s not so bad in practice?
But anyhow, thoughts?
mahlen