davidestevens

Max 7.0.3. Retina Macbook Pro. OSX 10.10.3

Very large patch, with an unnamed [transport] at the top level.

Several bpatchers contain [metro 8n @active 1]s.

I opened new views of a couple of the bpatchers and used the bang from each metro to trigger a pulsed tone (bang->function->line~-> *~ ; cycle~ via the *~ ) (I also have the pulses panned l/r and an 8ve apart to make it easier to hear what's going on)

As both metro are @active 1, they should presumably start at the same time when i turn the transport on?

The pulses seem to be running at the same rate, but one is slightly (but noticeably) later than the other, as if that metro started slightly later than the other one. Shouldn't they be exactly in sync? Is this an inevitablility when running metros in a very large patch?

EDIT Hmm. I tried sending the bang from one of the subpatchers to the other, and using timer to see the difference (though I suppose sending adds a bit of a delay). According to that, there's an 59ms at 120bpm difference between the clock pulses. (and delaying the pulse from one of the clocks by 60ms puts them pretty much in sync). At 60bpm the difference is 117ms (ie almost 120ms). There's a pattern here, isn't there.

Very large patch, with an unnamed [transport] at the top level.
Several bpatchers contain [metro 8n @active 1]s.

I opened new views of a couple of the bpatchers and used the bang from each metro to trigger a pulsed tone (bang->function->line~-> *~ ; cycle~ via the *~ ) (I also have the pulses panned l/r and an 8ve apart to make it easier to hear what's going on)
As both metro are @active 1, they should presumably start at the same time when i turn the transport on?

The pulses seem to be running at the same rate, but one is slightly (but noticeably) later than the other, as if that metro started slightly later than the other one. Shouldn't they be exactly in sync? Is this an inevitablility when running metros in a very large patch? 

shouldnt-several-metros-synced-to-a-transport-pulse-together

https://cycling74.com/forums/timepoint-mystery/

https://cycling74.com/forums/transport-does-not-start-be-beginning-of-first-bar/

See this thread:https://cycling74.com/forums/timepoint-mystery/
and thishttps://cycling74.com/forums/transport-does-not-start-be-beginning-of-first-bar/
for possible answers.


> In the help patch, the metro’s time interval is 4n, meaning that the bangs that come out of it will be spaced a quarter note apart, but that does not guarantee that those bangs must always be precisely on the transport’s quarter-note grid

That strikes me as a little counter-intuitive! And somewhat less than useful!

Anyway, if I add eg @quantize 16n to my metros, they should all be in sync (I'm not bothered about the first pulse being in time).

But what happens if I use a menu attached to metro's 2nd input to change the quantize value? (which is what I'm doing at the moment). Does the metro I've changed then lose sync? If so, would it work better/any differently if I changed the quantise value using attrui?

Anyway, if I add eg @quantize 16n to my metros, they should all be in sync (I'm not bothered about the first pulse being in time).
But what happens if I use a menu attached to metro's 2nd input to change the quantize value? (which is what I'm doing at the moment). Does the metro I've changed then lose sync? If so, would it work better/any differently if I changed the quantise value using attrui?


EDIT - a bit more experimentation seems to show that this works (in a new empty patch, with a [transport] in it...

If I add the @quantise attribute to a metro, it starts running, even with global transport off.

All I want is to have all of my metros start synchronously when I turn global transport on (represented by an unnamed transport object at the top level of my patch).

Create metros like this - [metro @quantize 16n @active 0] or [metro @transport @quantize 16n @active 0]

and then use a single toggle (using s/r pairs) to turn all of the metros on at the same time?

And what's the functional difference between [metro 16n @active 1] (which is what I've been doing) and [metro @quantise 16n @active 1] ? (presumably [metro 16n @quantize 16n @active 1] is meaningless (it doesn't run!))

EDIT - a bit more experimentation seems to show that this works (in a new empty patch, with a [transport] in it...
[metro 16n @quantize 16n @active 1]

I'll try that out now in my patcher.
=========

If I add the @quantise attribute to a metro, it starts running, even with global transport off. 

Create metros like this - [metro @quantize 16n @active 0]  or  [metro @transport @quantize 16n @active 0]
and then use a single toggle (using s/r pairs) to turn all of the metros on at the same time?

And what's the functional difference between [metro 16n @active 1] (which is what I've been doing) and [metro @quantise 16n @active 1] ? (presumably [metro 16n @quantize 16n @active 1] is meaningless (it doesn't run!))


You wrote, "...what happens if I use a menu attached to metro’s 2nd input to change the quantize value? (which is what I’m doing at the moment). Does the metro I’ve changed then lose sync? If so, would it work better/any differently if I changed the quantise value using attrui?" The second inlet of metro is for changing the 'interval' value, not the 'quantization' value. Those two attributes are not automatically or obligatorily linked (although you may very often want them to have the same value). To change the quantization value, send a 'quantize' message in the left inlet (or use attrui).

You wrote, "That strikes me as a little counter-intuitive! And somewhat less than useful!" Mari thought the same thing, and I acknowledge that it's reasonable to think that most people would want a tempo-relative (i.e., transport-governed) metro to be quantized to the transport's time grid by default. However, the way the transport system is designed, the premise is that just because you want the metro's bangs to be spaced at a particular interval (such as a 4n apart) doesn't mean that you necessarily want them all to be moved to (quantized to) land on the beat. See my discussion with Mari about this in the latter part of the first thread I cited.

Here are a few principles about transport and metro that may be obvious, but I'll say 'em anyway.

When a metro's interval is specified in terms of tempo-relative units (e.g., ticks, note values, bbu), it's governed by the transport. It progresses if and only if the transport is ON 

A metro may be governed by the transport (by giving the metro a tempo-relative interval), but the transport and the metro can always be controlled (turned on/off, changed, etc.) independently of each other.

The attribute 'active' in the metro object is synonymous with ON. So by typing in '@active 1', you're initializing the metro to be ON. If that metro's interval is specified in absolute time units (e.g., ms, samples) it will progress even if the transport is off. If that metro's interval is specified in tempo-relative units, it will progress whenever (if and only if) the transport is ON.

But if some message turns a metro off, it's OFF, even if its object box contains '@active 1'. In other words, typing that into the object box initializes the metro as ON, but it can be turned off, and stays off till it's once again turned on somehow.

The 'quantize' attribute means "always snap to the next specified grid unit of the transport (if the interval is specified in tempo-relative units)". A metro is not quantized by default. If you explicitly start a metro right on a grid point (say, by starting it at the same instant you start the transport at time 0) it will stay synched to the grid. But if it's started in between transport grid points (e.g., at time 16.1.7) it will remain offset from the grid by that amount of ticks. Or, if the metro is on the grid, but then the transport is caused to leap to a new time in between grid points, the metro will no longer be on the grid. So you can see that there are ways for a metro to have a stable tempo-relative interval, such as 4n, yet not send its bangs right on the beat.

When a metro's interval is specified in terms of tempo-relative units (e.g., ticks, note values, bbu), it's governed by the transport. It progresses if and only if the transport is ON and the metro itself is ON (i.e. "active").

The 'quantize' attribute means "always snap to the next specified grid unit of the transport (if the interval is specified in tempo-relative units)". A metro is not quantized by default. If you explicitly start a metro right on a grid point (say, by starting it at the same instant you start the transport at time 0) it will stay synched to the grid. But if it's started in between transport grid points (e.g., at time 16.1.7) it will remain offset from the grid by that amount of ticks. Or, if the metro is on the grid, but then the transport is caused to leap to a new time in between grid points, the metro will no longer be on the grid. So you can see that there are ways for a metro to have a stable tempo-relative interval, such as 4n, yet not send its bangs right on the beat.


Is it worth trying phasor~ with 8 rate~ objects with one transport ?

@christopher - that's _really useful. Thanks. IMO it would be worth adding your explanation to the Timing tutorial.

That also explains something else that puzzled me while I was trying to sort this out - why [metro @quantize 16n @active 1] runs whether or not [transport] is on, and [metro 16n @quantize 16n @active 1] follows [transport]'s on/off state.

Sensor control and internal control of my sound modules now sounds the tightest it's ever been!

@christopher - that's _really useful. Thanks. IMO it would be worth adding your explanation to the Timing tutorial.
That also explains something else that puzzled me while I was trying to sort this out - why [metro @quantize 16n @active 1] runs whether or not [transport] is on, and [metro 16n @quantize 16n @active 1]  follows [transport]'s on/off state.

Sensor control  and internal control of my sound modules now sounds the tightest it's ever been!

Shouldn't several metros synced to a transport pulse together?