Ableton & M4L Sync problem
Hi everybody,
I have two timing problem using Max in Ableton. I prepared a very simple patch which I attached and hopefully shows what I am dealing with.
After opening the Live-Projekt (Ableton 8.1.5, Max 5.1.5) you will see first the Button on the left side which is updating the live.observer object. This you have to trigger if yyou switch to edit mode or save the M4L-Patch.
Actually I dont know why I have to do and it seems to be another bug…
PROBLEM 1
Then you see the first metro on 4n and it is active (gain). Start and Stop Ableton and you will hear it is synched to the Metronome of Live.
Turn the first Gain down and open the second one. I programed this one like each quarter of the 16n metro is hitting the click. What I expected is a tight trigger like the 4n. But it is not. Start and Stop Ableton more than once and you will hear it is out of sync with the Live-Metro. So the higher the timing resolution is, the less accurate the timing-objects are working.
For this I found an alternative:
The third gain is a click which is coming from the transporter directly. I used the M4l.bg.14.StepSequencer example in the Live-Tutorials and calculated the quarters by using the ticks (% 480 = 4n).
I am not so happy with this solution because all timebased objects are really mighty (metro, delay~, phasor~) and I was really happy when I figured out the whole new time-system in Max5 – no, it was like HEAVEN!
So please try to fix this communication problem between Ableton and M4L! Or did I do something wrong?
Can you confirm this problem?
PROBLEM 2
With this tick based alternative I tried working on two machines synced by an M-Audio 410 (Mac 10.5.6) to a Behringer BCF2000 (WinXP, Realtek Soundcard on board).
The synchronisation was not very tight. I was able to hear that because of the Live-Metro.
It could be the soundadapter, but in the worst case it is Ableton… can anybody confirm? Has anybody experience with synced machines via Ableton?
Thanks a lot for reading all this in the first place. If you have any idea you would save my collegues and my performance tomorrow… and on friday too
- 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.
http://cycling74.com/forums/topic.php?id=28265
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
counter reset
Johannes,
thanks for clarifying the reset issue.
So your original patch seems to confirm my assumption that metro alone doesn’t sync properly. I think it would be helpful to make a clear demonstration since cycling apparently isn’t aware of the issue/bug.
Good luck with your performance!
The reason your patch is a bogus test of timing accuracy in MaxMSP is that you neglect to take the location of Max’s transport into account when you restart the transport.Max’s transport does not reset to 0 automatically like Live, it keeps going.
In Live, I cannot fault this, if I run it with Live’s metronome, no matter how many times I stop and start it.
Andrew,
after some more testing I can confirm that metro without transport works well for me too. The problems I had were related to counter resets based on the ‘ObserveTransport’ object which delivers the numbers 1-0-1 at start, i.e. a "false" stop message immediately after start.
I’m still curious if this behavior is intentional or a bug?
I was running into the 1-0-1 issue as well. I got around it by setting a live.toggle up to set the is_playing status, rather than observing it, and keymapping the toggle. Then I tap the toggle’s output for my fake "observe playing status" and get perfect 0/stop 1/go correlation. Hope that’s clear.
If you don’t use shift_play (i.e. continue) you can use the raw ticks output…I found this the most stable, its what I use. "Transport Play Status Bounce" is very irritating…it has affected my life in profound ways. Andrew knows what I’m talking about…
(I intentionally tried to coin a phrase right there)
I have a feeling we are looking at what’s really going on behind the scenes: like a play message is received, and since its not a continue, live stops to reset, and then plays? Has anyone tested it with continue?
amounra,
I think your feeling/interpretation is correct.
If you set Live’s transport to 1.1.1 and start from there you get a single 1.
And the same happens with continue.
FWIW, I’ve measured that the first "1" coming from ObserveTransport arrives about 2ms earlier than the first tick from transport (or metro). In theory this could be used to trigger some action at start just before Live actually starts running. But I’m not sure if this behavior is intended and reliable.
Any comment from the developers on this?