[chuck-users] Strategies for Complex Timing
vtatila at mail.student.oulu.fi
Sun Mar 18 09:21:57 EDT 2007
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
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
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:
More information about the chuck-users