extra metro bangs when looping transport
When I loop a transport back to a non-quantized metro's autostarttime, I get an extra bang. I can almost convince myself this is expected behavior (because it's not quantized) but I can't convince myself it's desirable.
Using @quantize seems to fix it, but I am avoiding @quantize because of a bug I posted recently (http://tinyurl.com/64sj63)
I have a workaround for the patch I'm working on now, but I wanted to point this behavior out since it could be problematic for people. (Max 5.0.3)
Adam Murray schrieb:
> When I loop a transport back to a non-quantized metro's
> autostarttime, I get an extra bang. I can almost convince myself this
> is expected behavior (because it's not quantized) but I can't
> convince myself it's desirable.
>
> Using @quantize seems to fix it, but I am avoiding @quantize because
> of a bug I posted recently (http://tinyurl.com/64sj63)
In a correct world, it would send the end point of the loop and the
start point at the same time. The end point seems to be converted
already into the start point (they are the same in a way).
A zl change after the when seems to fix the double start, but I would
not rely on it, because it could be also that the end time and beginning
time will come out of when...
The @quantize bug happened only if you switch off the metro in between,
maybe its done like that for getting these scenarios working correctly...
I'd use @quantize and no autostart... (play with the position of the
second toggle...)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Quote: Stefan Tiedje wrote on Thu, 03 July 2008 22:33
----------------------------------------------------
> In a correct world, it would send the end point of the loop and the
> start point at the same time. The end point seems to be converted
> already into the start point (they are the same in a way).
> A zl change after the when seems to fix the double start, but I would
> not rely on it, because it could be also that the end time and beginning
> time will come out of when...
I see what you are saying, but a [when] -> [change] fixed my problem so I'll continue using that for now. I don't normally loop the transport. It's only when I'm testing a particular sequencer segment. The first note was louder than the others because it was being triggered twice. Not really a big deal, just something to be aware of.
> The @quantize bug happened only if you switch off the metro in between,
> maybe its done like that for getting these scenarios working correctly...
>
> I'd use @quantize and no autostart... (play with the position of the
> second toggle...)
I've been making abstractions for synchronizing playback of sequences using the transport system. I didn't want the metros running all the time because I will have a lot of them. So using autostart and autostarttime is an important part of this system, it's how I schedule everything within the timeline of the piece. And unfortunately when I use @quantize, it pretty much never hits that first beat...
I see the same behavior if I don't use autostart and instead use a [timepoint] to start the metro. I guess it takes a bit of time for the [timepoint] to process and start the metro. By then, the quantization point has already passed and the metro won't fire. But when the @autostarttime is exactly at a quantization point, [metro] should do something to compensate for this and do what you would expect (fire a bang).
I am concerned that when using many non-quantized metros, things are going to get out of sync. So probably I will need to figure out how to get this all working with quantized metros. I'll share more experiences after I spend more time with it.
Quote: Adam Murray wrote on Fri, 04 July 2008 13:01
----------------------------------------------------
> I am concerned that when using many non-quantized metros, things are going to get out of sync. So probably I will need to figure out how to get this all working with quantized metros. I'll share more experiences after I spend more time with it.
Tonight I tried my darnedest to get a few non-quantized metros out of sync. I couldn't do it. I have a massive patch that takes 10 seconds to load and spikes the CPU, opened it a few times, did lots of GUI stuff, did intensive jitter stuff. If I turn off overdrive the bangs will come very irregularly (as expected), but they always stayed in sync.
I didn't understand what @quantize was for, but now I think I do. When starting a metro at some arbitrary time, @quantize ensures it bangs on the beat. Non-quantized metros stay accurate with respect to their start time (which may not be exactly on a beat). When using @autostarttime to ensure the metro starts on the beat, then @quantize is not needed.
Let me know if I am misinterpreting how this stuff works.