[chuck-users] Strategies for Complex Timing

[Veli-Pekka Tätilä]

Hi list,
Here's an abstract question for a change:
If I'd like to create a large-scale patch in which various UGens need to 
work at various different, and possibly changeable rates, what would be a 
good strategy to go about this? What kind of tacs do you currently use?

Here's a fictitious example. Say I have two of my OneOfN switches for oscs 
that are updated at 10 Hz to save CPU cycles, an envelope follower that is 
updated every sample and a couple of short delays that are synchronized 
based on the notion of a musical beat and tempo. Computing musical time 
given the meter and tempo in bpm is not a problem nor is figuring out the 
sampling rate, though utility functions would be appreciated.

The basic issue is that when you do add something to the now time, pardon my 
Cakewalk lingo, you'll have to take that addition into account when timing 
all the rest of the modules. And if you have multiple instances of a module 
that should run at the same rate, you'll have to structure the code in such 
a way that these modules get updated at the same time, if I've understood 
things correctly. This can soon get very messy.

Here are some tacs that come to mind:
Have a counter that is inced every sample and divide its frequency by 
various rates using the modulo operator to continuously, say poll the input 
attached to my OneOfN switch. This is the method they use in basic digital 
logic frequency dividing a high frequency clock source to get various nicer 
rates out. But the counter might overflow some day and branching takes a bit 
of CPU.

Or another thing. IMplement an infrastructure for timers in which, a 
particular method of all attached objects gets called when-ever a specified 
amount of time has elapsed. THen spork a child process for each such timer 
and have them run concurrently , without having to worry about timing after 
the initial setup. I'm not sure how heavy context-switches are inside the VM 
shreads, though.

Lastly, this came to mind. Or don't try to save CPU at all and let chucK 
update everything at virtually every sample, even though you know a human is 
not able to generate controller events very fast, for example. I think 
SynthEDit uses this last tak.

I have a nagging feeling somewhere in my head that I've misunderstood 
something about timing. That if I just keep adding an arbitrary amount to 
the now time everything will just get automagically updated every sample. 
The only thing i'd have to explicitly worry about then Would be the stuff I 
need to poll periodically. I'm still a bit unsure.

So any comments and hints appreciated.


With kind regards Veli-Pekka Tätilä (vtatila at mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/