Metro @active transport start not synchronized
Why would that be? This is straight from the help file.
You have one metro that is using a transport named toto with a tempo of 72. The other metro is using the global transport and whatever tempo is set there.
Additionally, it is often more useful to post an example using the "copy compressed" feature in max and paste it in the the forum. Here is an example to works, both metros are using the global transport
Thats true, but the metro attached to print is using the toto transport. The other one isn't active or printing.
I included the example from Max's help file, which i thought would be just as easy and copying from the clipboard - it would also demonstrate easily that this issue seems to be a native function of metro.
I have no doubt that two metros running off of the same transport will be synchronized, but thats not the issue. The issue is, as seen in the time stamps, that when you activate the toggle, there is a delay between that toggle on and the first bang of the metro. This strikes me as odd. Even When using a zero message to "rewind" transport, the delay occurs. It appears not to be random, but rather is based on some other unknown start time, almost as if metro has its own internal start time, not synchronized to the start time of the transport. Thats all well and good if one simply needs a consistent, repeating bang, but for coordinating sequencer sequencer starts, its unusable.
I cannot get the clipboard example you included to work. Was autostart the intended attribute? I switched to @active 1, and can indeed replicate the behavior you proposed, but i added a couple changes to demonstrate the behavior in question.
thank you
I think this patch may help to further demonstrate this behavior. With delta time on, you can see that the transport start is indicated by the TransBeat Print to occur significantly before the Metro1 and Metro2 occur
I tried something different here, and this seems to be an accurate way to coordinate sequencer starts - any input?
Quantization must be activated for the metro, and when changing note values to the metro interval, quantize must be changed as well. Seems to clear it up!
ah yes, glad you figured it out. I believe the way it works is if you set a metro to a time interval like 4n, it will continue at that time interval relative to when it was started. This may or may not line up with a quarter note in the transport, depending on if it was started exactly on a quarter note. Quantizing gets around this and ensures it start on the time interval specified.
sorry that my example was sub-par!
Yes! Thats what i suspected. Metro always runs at note value (or whatever) interval relative to its first start. Your wording was conceptually more concise than mine.
And please know that i was not criticizing your patch, this is always a working-through process on the forums for me. People get salty on here sometimes and i don't wish to contribute to that.
Dialectic results are much appreciated.
oh i didn’t take it as salty at all. i realized after you mentioned it, i could have put more thought into the example. no big deal!