Ableton & M4L Sync problem

- When you are quantizing, use the unit you wish to quantize to

metro 4n @quantize 4n

If you use some other value, metro will think it's fine to bang on one of those subdivisions.

- @autostart 1 @autostarttime 0. means

"The first, and only the first time you go past point 1.1.1 in live, then start this metro"

I think you want @active 1, which means, just start and stop this metro with the Live transport

As far as syncing copies of Live together over MIDI, it's not super tight, but you can usually get it to work, IME.

A way of getting better timing is to have everyone in the group playing one live set on one computer.

-A

Hi,

as far as I was able to figure out the quantization is depending on the resolution in your whole environment.
https://cycling74.com/forums/metro-32n-global-transport-asynchronous
So if there is a 32n metro and a 4n metro I have to quantize both to the highest value ie 32n.

I have to admit: the autostart/autostarttime attributes are not necessary in my case.
So I replaced autostart/time by active 1.

But also without them I still have this problem!

Weird...

>So if there is a 32n metro and a 4n metro I have to quantize both to the highest value ie 32n.

No , this is not correct. Use metro 4n @quantize 4n @active 1 if you want to mimic Live's metronome.

Cheers

-A

I experienced, that a 4n is not the problem. But the higher the resolution gets, the more inaccurate is Max. And this is also outside the M4Live world. Try this
[metro 4n @quantize 4n @active 1]
and
[metro 16n @quantize 16n @active 1]
and you will hear the difference.

Make sure you have Overdrive on when running these kind of things in Max.

I've run a bunch of our standard timing tests, I'm not seeing any problems with the latest revisions of Max and MFL.

-A

In my experience, for sync'ed timing you can't use the output from metro directly. Instead it must be connected to a transport (ie. polling) and then you can use the output of transport. This works perfectly for me.

But perhaps it was only needed on earlier versions (?)

depends what you want.

If you just want bangs, then use metro.

It is true that you need to poll transport quickly in order to achieve a high level of accuracy with your position data, but this is another issue,from what I can tell at least.

-A

@bluemilk

I've looked at your patch and noticed that the counter reset is wrong.
You are sending a bang instead of the number 1.
With this correction the patch works for me as expected.

Hi,

thanks for all the answers so far. I am really happy that you took part of it.
I will do a little conclusion:

a) to have a high accuracy I will use the transport / tick alternative in the Ableton-Patch shown above like actually all of you recommended. (M4L-related)

b) Andrew says that he does not have the timing mismatch in the simple patch which I copied in this thread above. But I still do, although I changed the metro-attributes (Max-related only). I can reproduce the bug the moment I start/stop the Transport more than 2 or 3 times. This is still a major-bug to me... I can still do some convincing here by making a video of my actions.

c) the third inlet of a counter does understand a bang and is resetting the index to the given min-value. Please try it out broc and then you can see the reset this way is fine.

I hope with all these suggestions I may have a nice performance this evening here in Austria.

Thanks a lot again!

Best
Johannes