Dan Nigrin

Say I have multiple metro objects, set to output quarter notes. Some of these metro objects exist in bpatchers that are dynamically created by scripting, at arbitrary times. What I would like to have happen is that each of these metro objects outputs their quarter notes at exactly the same time, regardless of when they are created. I am just using the one master Max transport for the whole patch.

Suggestions for best approach? I am looking for the tightest possible synchronization of the metro objects as possible....

Say I have multiple metro objects, set to output quarter notes.  Some of these metro objects exist in bpatchers that are dynamically created by scripting, at arbitrary times.  What I would like to have happen is that each of these metro objects outputs their quarter notes at exactly the same time, regardless of when they are created.  I am just using the one master Max transport for the whole patch.

Suggestions for best approach?  I am looking for the tightest possible synchronization of the metro objects as possible....


synchronizing-multiple-metro-objects

My question is; why not script-generate receive objects that all get their data from the same metro?

Because I am using the interval attribute of the metros to easily generate subdivisions of the quarter notes (i.e. eigth, sixteenth, etc...). I'm sure I *could* do that division outside of the metro objects, but seems better to do directly within the metro?

Because I am using the interval attribute of the metros to easily generate subdivisions of the quarter notes (i.e. eigth, sixteenth, etc...).  I'm sure I *could* do that division outside of the metro objects, but seems better to do directly within the metro?


You could try using a quantize attribute like @quantize 4n.

Been messing with that earlier today - so far not doing what I want it to, but it might be user error! Thanks broc.

Been messing with that earlier today - so far not doing what I want it to, but it might be user error!  Thanks broc.


My approach would be to use a faster clock and a counter and send the count to all your various subpatchers, then use the modulo operator to create the actual clock in each subpatcher.

Good idea Chris, will try that - and you guys are probably right in general, to get rid of the multiple metros in the first place...

Did you try [metro 10 ticks @active 1 @quantize 16n] with a master transport outside of your bpatchers ?

No, I was doing [metro 16n (or 4n, or 8n, etc..) @active 1 @quantize 16n] . That didn't work too well...

No, I was doing [metro 16n (or 4n, or 8n, etc..) @active 1 @quantize 16n] .  That didn't work too well...


For syncing to quarter notes you'd need using '@quantize 4n' regardless of the interval.

But sending counter data from a global metro is probably the better solution anyway.

For syncing to quarter notes you'd need using '@quantize 4n' regardless of the interval.
But sending counter data from a global metro is probably the better solution anyway.


I vote modulo, it has never failed. both the counters and the main metro have no arguments. You'll want a way to reset each counter separately and all at once, use send/receive from the main patch.

The only issue might be with triplets etc. if you want some funky subdivisions, then you'd need a much faster main clock as mentioned above. Maybe try a clock 12X as fast as your quarter-note, so you can get down to smaller subdivisions in both duple and triple?

Thanks all for the comments - I will be trying the modulo approach, and will probably go with 24 ppqn, so that I can substitute MIDI clock rather than Max-generated clock if the need arises....

synchronizing multiple metro objects