David

In this patch a toggle sets the current position of the transport at 0 and also sets a metro banging every eighth note. If I restart Live's transport to zero by double-clicking on the Live transport stop button, press Start Transport in my patch and then start the Live Transport then my patch shows tick outputs at 0 and 240 for a while, but then it falls off into 239 and 479, occasionally flipping back to 0 and 240. I wondered if overdrive might help but it seems to be ticked, and is greyed out. Can anyone explain this behaviour please. I want a reliable sequence of tick values. Is there a better way of achieving this?

unreliable-tick-values-from-transport

You are polling the transport with a Max event, and the event has timing accuracy not more exact then the timing accuracy of the Max scheduler in overdrive ( always the case in MFL ). If you want more precisely timed events in Max, then you will need to move into the audio domain.

Thanks for your reply. The device tests for equality on the tick output of the transport and if equal triggers the creation of a MIDI note. If I can't get reliable tick values coming out of the transport this way then I need another way of triggering the notes. I don't need accurate triggering down to 1 tick, 32nd notes would be sufficient, but I want it synchronised with Live's transport. I will try to find something to read about the MAX scheduler accuracy. All suggestions will be gratefully received.

David, this ought to work, actually. I am getting rock-solid performance within MfL using metro -> transport.

I have overdrive on, and I get a solid 0, 240 thing going on in your patch too. If I scrub around in the transport it's off, of course, because there's no sync really.

fwiw we use a construction like this one in my orchestra - it's quite a bit more expensive, but it's also tight as hell.

I have overdrive on, and I get a solid 0, 240 thing going on in your patch too. If I scrub around in the transport it's off, of course, because there's no sync really. 

fwiw we use a construction like this one in my orchestra - it's quite a bit more expensive, but it's also tight as hell.


I think your reply has helped me to answer my own question. I can get 32n accuracy by running a counter (min 1, max 8) off the metro and then testing for equality on the counter values. Thanks again.

We are comfortable doing things like swing operations and polyrhythms off of the main clock, on a tick level.

We even do tick-level latency compensation over the network. It's really the best sync I've ever come across - even though it's not sample accurate.

We are comfortable doing things like swing operations and polyrhythms off of the main clock, on a tick level. 

We even do tick-level latency compensation over the network. It's really the best sync I've ever come across - even though it's not sample accurate.


btw, don't use a counter, unless you want a complicated reset scenario. Use the "raw ticks" output, like I did in the patch I posted above.

Hi. Thanks Wetterberg for your patch. I had not been aware of the raw ticks option. I am still very hazy about the arguments that you have in the metro (metro 1 ticks @quantize 1 ticks @active 1) so I will need to read more about this. I have modified you suggestion and included it in my patch. The output from the equality tester drives a prob, which changes state depending on the input and resets the argument of the equality tester. With the prob values given in the patch this cycles nicely up to a tempo of about 130 but it then starts missing some transitions. I thought that this was because there is not enough time for the prob state to change and reset the equality tester value before the tick value has already gone past the new value, but if I change the message box that sets the prob to (0 60 1, 60 0 1) it still seems to miss transitions at about the same frequency at 130bpm. I'd love to know if there is a way of making this run reliably faster than 130bpm. 

Your metro doesn't behave as expected since the syntax is not correct: for interval in ticks the attribute @interval must be used (see reference page).

Thanks broc. I tried that and it seems quite reliable now. I noticed that the max help on metro uses an example in which the interval is set as 4n without the @interval attribute flag.

This might be why I got into the habit of using the attribute value with incorrect syntax.

Thanks broc. I tried that and it seems quite reliable now. I noticed that the max help on metro uses an example in which the interval is set as 4n without the @interval attribute flag. 

This might be why I got into the habit of using the attribute value with incorrect syntax.


yeah, you don't normally need the @interval, since the first argument of metro *is* the interval, as far as I understood it. Kind of inconsistent that the setup is different for ticks, imo.

huh... just tested, and the syntax may be wrong according to the reference, but [metro 1 ticks @quantize 1 ticks @active 1] definitely outputs every tick.

Are you guys getting different results? Mine works swimmingly, even at 150 bpm.

huh... just tested, and the syntax may be wrong according to the reference, but [metro 1 ticks @quantize 1 ticks @active 1] definitely outputs every tick. 

Are you guys getting different results? Mine works swimmingly, even at 150 bpm.


According to my test without @interval attribute, '1 ticks' seems to be interpreted as '1 ms' and thus metro runs independent from transport and tempo. Unfortunately there is no error/warning message.

weird - I ran tests, I could print every tick produced by a very fast global transport.

unreliable tick values from transport