Mari Kimura

I long didn't use timepoint object and maybe reminded why....

In this example patch, I start the transport, and the timepoint bangs out the cues correctly. But then I stop the transport, rewind by clicking message 0. then restart the transport, and the cues start to go out of sync.

The mystery is that each time is different; sometimes the second time around it is still fine, or if I restart Max, it is spot on. But sometimes if I don't restart Max and simply start/stop transport, the timepoint goes out of sync, sometimes by as big as a beat.

Am I missing an attribute or something? If anyone can tell me what I am doing wrong here, I appreciate!

Hi,
I long didn't use timepoint object and maybe reminded why.... 

In this example patch, I start the transport, and the timepoint bangs out the cues correctly.  But then I stop the transport, rewind by clicking message 0. then restart the transport, and the cues start to go out of sync.

The mystery is that each time is different; sometimes the second time around it is still fine, or if I restart Max, it is spot on.  But sometimes if I don't restart Max and simply start/stop transport, the timepoint goes out of sync, sometimes by as big as a beat.

Am I missing an attribute or something?  If anyone can tell me what I am doing wrong here, I appreciate!


timepoint-mystery

It's not that timepoint is doing anything wrong. It's that your metro is no longer sending its bangs on the beat, 'cause you stop and/or rewind the transport in between beats, not perfectly on the beat. The fact that the metro is "@active 1" but not "@quantize 4n" means it gets out of sync with the transport if you stop and rewind the transport in between beats. If your metro is "@quantize 4n" your patch should look fine, 'cause the metro is quantized to only send bangs on the beat.

For a longer explanation, see this thread: 

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

For a longer explanation, see this thread: https://cycling74.com/forums/transport-does-not-start-be-beginning-of-first-bar/


Aha!!!! Thank you so much, that solved it.... You really are the king!!!!

Aha!!!!  Thank you so much, that solved it.... You really are the king!!!!

ps. Just wondering, why aren't these features 'default' so laymen like us don't have to suffer and bother the pros like you every time?? :) :) I don't think anyone wants it to go out of sync...???

ps.  Just wondering, why aren't these features 'default' so laymen like us don't have to suffer and bother the pros like you every time??  :) :)  I don't think anyone wants it to go out of sync...???


A lot of things default to whatever the default in 1989 was. Which was not necessarily designed with the mass of new users with very different notions of what "the most obvious thing" is from 25 years ago.

The thing is that there are zillions of existing patches out there, and when a new feature is added (like a quantize attribute -- the original metro didn't even have attributes, let alone one for quantization), the rule is to add things in a way that shouldn't break existing code.

Without disputing anything @Peter Castine wrote, I think a way could have been found for transport-governed metro objects to be quantized by default. The question, though, is: is that really the best default?

Since transport and its related note-value time syntax are newish features, no old pre-transport patch is going to have a [metro 4n] object in it. So it's true that a decision could have been made that "when the typed-in interval argument is a tempo-relative timing, that means the metro will be governed by the transport, so we should assume the person wants to synchronize events with the transport's time grid, so in that case @quantize should on and should be the same as @interval by default".

Instead, a decision was made that @interval and @quantize are not inherently linked. For example, a person might want to have a [metro 4n] but start it at timepoint 1.1.240 for offbeat performance. In that case, if quantization were the default, the person would be wondering, "How come my metro can't play on the offbeat?! Oh, I have to turn off quantization? Why is that on by default?!" You get the idea.

Since transport and its related note-value time syntax  are newish features, no old pre-transport patch is going to have a [metro 4n] object in it. So it's true that a decision could have been made that "when the typed-in interval argument is a tempo-relative timing, that means the metro will be governed by the transport, so we should assume the person wants to synchronize events with the transport's time grid, so in that case @quantize should on and should be the same as @interval by default".

Instead, a decision was made that @interval and @quantize are not inherently linked. For example, a person might want to have a [metro 4n] but start it at timepoint 1.1.240 for offbeat performance. In that case, if quantization were the default, the person would be wondering, "How come my metro can't play on the offbeat?! Oh, I have to turn off quantization? Why is that on by default?!" You get the idea.


I just showed this whole 'saga' to Hervé (computer scientist husband). He suggests that the metro helpfile should just list the "quantize" options on the FRONT PAGE, and 'advertise' the fact that you need this attribute, and possibly with a little usage example. "quantize" is listed in the attribute list, but there is no example nor how-to. He says it seems like such a common usage (not to go out of sync).

For me personally, "1.1.240" trigger option should be THE option for those who want it :)

I just showed this whole 'saga' to Hervé (computer scientist husband).  He suggests that the metro helpfile should just list the "quantize" options on the FRONT PAGE, and 'advertise' the fact that you need this attribute, and possibly with a little usage example.  "quantize" is listed in the attribute list, but there is no example nor how-to. He says it seems like such a common usage (not to go out of sync).

Timepoint mystery