Variable bandwidth for trig randomizers

[Antimon]

I have noticed that the randomizers on the G2 are pretty expensive. I like to use the trig randomizers to change attenuators on beats, and one feature that would be cool is to be able to set the bandwidth for the randomizer to e.g. 4, 16 or more frames, so that pre-calculation of the next pseudo-random number would need 4 or 16 sample frames (or whatever you call it) to finish, and the cycle load would decrease. Then you would have more cycles over for bandwidth-sensitive stuff like oscillators. You wouldn't need to lose precision on the beat, since the randomizer would start calculating the next number as soon the current was retrieved.

Here's some pseudo code:

randomizer {
long currentNumber;
long nextNumber;
int nextNumberPartFinished = 0;
int framesNeededToCalculate = 4;

runEachFrame() {
if( nextNumberPartFinished > 0 ) {
calculatePart( nextNumber, nextNumberPartFinished );
nextNumberPartFinished--;
if( nextNumberPartFinished == 0 ) {
currentNumber = nextNumber;
}
}
}

long getNewNumber() {
return currentNumber;
nextNumberPartFinished = framesNeededToCalculate;
}
}


This will not be useful for Formants, and it assumes that it is possible to distribute the calculation of random numbers so that a function like calculatePart() can be implemented. Still...

Maybe there are other modules that you don't always need full bandwidth for, like most of the logic modules or LFO's...? Perhaps some kind of logic like this is already used in the Modular? I know this has been discussed in other threads here.

[blue hell]