Metro vs phasor~ vs cpuclock
Hi Community,
I'm looking for a little feedback on an approach. First some background:
For my project, I need several synchronized metronomes to produce bangs. They are all driven by the same tempo (in BPM), but I need to be able to individually set the number of bangs per measure. For example: 4 bangs per measure (quarter notes), 1 bang per measure (whole notes), and also larger, like 1 bang every 2 measures.
The easiest choice is the transport/metro objects using quantization for synchronization. I've been using this while building up the project, but have reached some limitations. The most difficult limitation is that the slowest rate of bangs produced by the metro is at 1n (I know there is a slightly slower bang rate), given a tempo. I was using counter to half and quarter the rate, which works well for one metro. The problem is that the counters would get out of phase, so to speak, with each other as I switched bang rates on different metros. I started thinking about the best way to initialize them so that the counters would always start at zero, but I wasn't sure that would solve the issue. The other limitation was a concern that the metros would eventually drift.
I've read numerous times about using phasor~ and edge detection to build a metronome, and was thinking about doing that, but I'd have to solve a synchronization issue across many different phasor~-based metronomes. Doable, but complicated.
The solution I came up with is using the cpuclock as the master metronome. The approach is to modulo the cpuclock with the time between bangs. The time between bangs comes from the tempo and the bangs per measure. I can use this to find out how much time until the next bang should be, then set a delay for that time. I find this works well -so far - since it automatically syncs across all the cpuclock-based metronomes, doesn't drift, should have better precision than metro, and uses less resources than processing a phasor~ at sample rate.
I was looking for some thoughts, comments on this approach. Is there something I didn't consider that makes this approach worse than using a phasor~? Patch is posted below. Bang at top starts the metronome.
How is using a single master phasor~ (I prefer to lock mine to the transport, but your mileage may vary ) and an arbitrarily large set of rate~ objects (with their sync attributes set to lock or cycle, as the circumstance/design would demand) complicated in a way that what you've posted isn't? Timing at audio rate is as tight as you're going to get. Heck, you can run rate~ objects off of the output of otherrate~ objects, even. :-) Perhaps I'm not understanding the problem properly....
Hi Max,
That actually sounds like a great way to do it. I hadn't thought through the implementation of phasor all the way, so didn't quite understand how easy or hard it would be. How do you compare the computational needs of processing many rate objects for edge detection vs. setting delays like in the patch above? Given the number of metronomes I need, I'm worried that the phasor object approach will be expensive.
Thanks!