Chris Graham

In Max7 I find that when the global transport is rewound and started, it does not start at the beginning of the first beat. It seems start a variable amount of time through the first beat. It acts as if the global transport is synced to some always-existing master clock. The problem can be seen by loading the transport help patch, setting it to a slow tempo and starting and stopping it a few times, each time rewinding before starting. There is clearly a variable amount of time until the first beat occurs.

How can I ensure that the beginning of the first beat occurs when the transport is actually started!

Apologies if this is answered somewhere in the forum but the lack of a search function makes it almost impossible to know!

In Max7 I find that when the global transport is rewound and started, it does not start at the beginning of the first beat.  It seems start a variable amount of time through the first beat.  It acts as if the global transport is synced to some always-existing master clock.  The problem can be seen by loading the transport help patch, setting it to a slow tempo and starting and stopping it a few times, each time rewinding before starting.  There is clearly a variable amount of time until the first beat occurs.  

Apologies if this is answered somewhere in the forum but the lack of a search function makes it almost impossible to know!


transport-does-not-start-be-beginning-of-first-bar

I think what you are witnessing in the transport.maxhelp file is 

 that the transport is not rewinding properly, but rather that the metro is not quantized to a particular time division of the transport's timeline, so it might report the time some number of ticks after the transport starts. 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 

 the transport's quarter-note grid. That might be a bit abstruse, so let me give an example.

In the help patch, the metro's time interval is 4n and its 'active' attribute is on, meaning "whenever the transport is on, the metro is on, too." Now imagine that you run the transport for a while, then you stop it, and you happen to stop it, say, 223 ticks into the beat. The metro stops 223/480 of the way to its next bang. Then you rewind the transport and start it again. The metro continues on its way, and 257 ticks later it sends out its next bang, triggering a report from the transport object, saying that the current time is measure 1, beat 1, and 257 ticks, and every subsequent bang of the metro will be offset by that amount. The transport started at time 0, but the metro didn't trigger the report till a bit later.

The 'quantize' attribute can solve many such problems. If you add "@quantize 4n" to the metro in the help patch, and follow the above steps, you'll see that when you stop, rewind, and restart the transport, the next bang out of the metro might be a few ticks late, but then it adjusts itself and only sends bangs out in synchrony with the transport's quarter-note grid. Better yet, rather than rely only on the 'active' attribute, you can instead explicitly start the metro at the exact same instant as you start the transport, and if your transport was rewound to 0 ticks, the metro will be in perfect synchrony with the transport's sense of the beat.

 will help, too. (Note that the metro that's banging the when object to report the current time is quantized to the nearest 16th note, so it is snapped to the transport's 16th-note grid.)

I think what you are witnessing in the transport.maxhelp file is not that the transport is not rewinding properly, but rather that the metro is not quantized to a particular time division of the transport's timeline, so it might report the time some number of ticks after the transport starts. 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 might be a bit abstruse, so let me give an example.

I hope that's helpful. Maybe this example will help, too. (Note that the metro that's banging the when object to report the current time is quantized to the nearest 16th note, so it is snapped to the transport's 16th-note grid.)


Thanks for the explanation. However no matter what I try, the first note after the transport is started is always shortened by some amount. Adding @quantize did not make it better. Attached is a simple example patch and a screen shot with typical results.

In the screen shot it can be seen that the duration from the start of the timer to the first beat is significantly less than the expected beat duration of 480 ticks. All other beats have a duration of about 480 ticks (although they do have a surprising amount of jitter).

I need the first note after the transport is started to be the same length as all other notes. i.e. The moment the transport is started should set the actual beginning of the first beat. Is there any way to do this?

Thanks for the explanation.  However no matter what I try, the first note after the transport is started is always shortened by some amount.  Adding @quantize did not make it better.  Attached is a simple example patch and a screen shot with typical results.

In the screen shot it can be seen that the duration from the start of the timer to the first beat is significantly less than the expected beat duration of 480 ticks.  All other beats have a duration of about 480 ticks (although they do have a surprising amount of jitter). 

I need the first note after the transport is started to be the same length as all other notes.  i.e.  The moment the transport is started should set the actual beginning of the first beat.  Is there any way to do this?


start it explicitly with your toggle at the same instant as you start the transport

As I mentioned above, instead of using the 'active' attribute to start the metro, you should start it explicitly with your toggle at the same instant as you start the transport. I think that will solve your problem.


I don't think that explicit start of metro is necessary, but just adding the 'quantize' attribute should solve your problem, like this.

Otherwise, posting your patch in copy-compressed format would be helpful.

Otherwise, posting your patch in copy-compressed format would be helpful.
https://cycling74.com/welcome-to-c74/


@broc If you read my (admittedly long and boring) description above, and try it yourself, I think you'll see that chris graham is correct. After a stop/rewind/restart of the transport, it takes an 'active' metro one bang to get itself quantized, so the first bang will not necessarily be perfectly quantized. That may not matter in many situations, but it does seem to matter in his, so I think resetting the metro is necessary.

this explanation should really be in the help file. I was struggling with confusing timing issues in my patch and was about ready to give up on max but the start/stop thing should solve it. Thanks!

Transport does not start be beginning of first bar?