Not a bad thought, but there are non-polyphony cases where this could be handy.
For example, in the BASICally preset “Quantize Octave”, the code walks a short sorted array range, trying to find the two values an input value new_in is between:
FOR k = 0 TO notes_len
if range[k] <= part AND range[k+1] > part THEN
' Found it!
prev_in = new_in
OUT1 = value[k] + octave
OUT2 = new_in - OUT1
OUT3 = abs(OUT2)
EXIT FOR
END IF
NEXT
This is only run when the input value changes, and range is pretty short (12 values in this case). So changing NEXT to NEXTHIGHCPU means that this will respond with the correct answer with no delay, and at unnoticeable cost.
But you raise a good point. My thinking is that, in the docs for BASICally, I can make a little chart of situations and suggestions for which variant to use:
- Initialization on startup → NEXT
- Running a calculation over a long array (more than 20 items) → NEXT
- Processing polyphonic audio → NEXTHIGHCPU
- Processing polyphonic CV, per sample accuracy is not required → NEXT
- Processing polyphonic CV, per sample accuracy would be good → NEXTHIGHCPU etc.
In point of fact, there are ways for the BASICally user to mitigate the CPU hit that NEXTHIGHCPU incurrs. It’s just a matter of trying to explain it all, and asking people to pay attention to something I’d rather they didn’t have to understand. I’ll likely hit up this community for notes later when I’ve written out a tolerable version.
mahlen