Ableton & M4L Sync problem
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…
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?
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.
as far as I was able to figure out the quantization is depending on the resolution in your whole environment.
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!
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]
[metro 16n @quantize 16n @active 1]
and you will hear the difference.
----------begin_max5_patcher---------- 760.3oc2X10aaBCEF9ZxuBOe4TZD9CBvjlT2uiopIBwMwafcF3rl0ple6CrI soMe434gP6FHw3XdOO98XebdZT.blbCqFB9D3qfffmFEDnapsgftuG.Ky1jW jUq6FLWVVxDJ3XyyTrMJc60OvU4KAKYULfRBt8mqyD7GY.zTwt9duTnpaZqs +H7jvtlEqK4hBlRO9ntFWk0LZbwhuUwxUF8gvzleCfPZuhRRZugCmDBt60AR tVsaj1M774Z8Im88avn8khHqTKE3Wp3YEv1G77nQsWFaIKDrGZF1CQAq.DdM AM9zAMgniSDUeiL8BAM9vfFkdlft6IlQP86ULyaENKSr.NF.gf67GW9vmAHO gkHjgGgo5a3IQmEKnifkDGvBuw36DQTxEKJXvqzwSS0gGlP2Mse0QYr+ik6K jMuWOkTSwlPLQ6riBcveSbXhrIFxTsFbsQ2ml7OtEDNwWI+IDi8FaUx+wl+o N.mZ9BQyi8IUxK34+Xqm7LjowZRDqoCE4.Vh5Yr30bFDUmlfLKK3TNCd3kyf i7TVSpFKnXMWnoN3NB+OLoI1TGAF4ZNSZOCE21xjjhM4FXW2xLw+6Xdh4WUU lndkrR4qsKLkKfhMH.GegfO8vfepiEEM9kaurJwge3X8xMfxdbdV9V3UxGjo HCRhdABZztq1e.hHOeJAeUNL1rXG1rwfKmRfNTNjPtbsPwp.g.DfdM3I5b3o iHZ7jboE+nGhGh64E6678InJYpJY6wqMm0V0cXavsY4J9uX9yaknSTl1sTpC Eghc0a4ebQ2mVT+Cq38XEJE6PsGdgU52GrfKd++siVxss+V.VKWWkua35jA3 UUOmUq3hLEWJ1qOouoOK4ymyD6utYIe9JYiquSBmXxzZEkZgjZRSA3dSRIVn HTOSIqzDoe0TrMZBO.0TR+poHazDse0DwVMg5OMQsPSQCSI0eyb1nHT+JIrk qf2eJxF2cOmvEN7L2gCNysM0B7NY+OmRXa0DZPUfxz+BJ07kmG8GZZ9eYC -----------end_max5_patcher-----------
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.
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.
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.
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!
----------begin_max5_patcher---------- 427.3ocyU9saBBCEF+Z3onoWyVnEqf6t8brXV3OcXWfVCTxby369JG.Q2PFt LcdgkvoG64662ozt01BGo1vKwnGPOgrr1ZaYAgpCX09tENObSbVXIjFNpRqU RrSyTpJcFWqeeMuYMvQgxTLZY6zqC0wqDxzmK3w5lLlEL+dWGDMXF7vsab++ Qj.0QE85cK5JirJWHMEBj.oOXS4ahVGbmsc8fyD8RNurLLk2UEMeCHRr2IsW u0dQI0khOfIHTiKNsiofU8XfWaFIAC6Xe7AKuLLGVd7iEhvrAYA8OiEZUZZF +jFWH0i2VIPakvH+bakcgaqR9alx7stZNWWnPTlq6D28dFs34LvvL3gOYL26 8u0hGkKWBr3Er.HAA.RKiNAVn2ZXIVUI07BDAQbG8yBGywBs+N5qjy4Dh.3D BHKju+XbhblbhMHmlc.mfpfyDxudQ.nz53GCuRUUQbG.Z2Qi50ZBuTKjgZg4 Vh9bLxFQ2myJQRBGltiJ4hj0JC9Zk.Z4fMxopH1DTzwp9RqnovnEWUEQlfhL WGY1+eK00nWUFQm3N6eqhLury9S.2xAKyB -----------end_max5_patcher-----------
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.
----------begin_max5_patcher---------- 296.3ocqR0zSDBCD8Ljv+gldF2PWbMqdR8ugYioTpriVlhvfhtQ+sao.q3tW VidoS38Ql48B6hBC3Y1NcCmcE6NVPvNGRfGqGIXBHfWJ6TFYiWHG0uZydjGO xQ5NxiWpoZK6bjc8ysRjf209OjJBdQyD6MTII0V.KtuVqngUKRDKRhYqR6eE WboerdQBayjIaKYzD8VkdvAOShE7u4evhTiak8rhDm+QbrsDPmS+oubtZTV5 UyuoFjF1sVSNelqgE5sIlfgbuAW5OaE2i8QTX+zMh+y8mx.pm97Dpo0K6eSO kVpAJPo421Sh+udJ8vdZ3T3F.O5+Neh6INn8Zrs0poDMT9wrYoNW2P.JIvhy Dk9SQag7bsmeelKg7JKfz3cv1bzoFE5Fe8Lb2VM -----------end_max5_patcher-----------
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?
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?