MIDI clock (slave) improvements in Live 8.2.4b1

Discussion of music production, audio, equipment and any related topics, either with or without Ableton Live
broc
Posts: 1151
Joined: Mon Jul 26, 2004 8:37 am

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by broc » Tue Jun 14, 2011 2:19 pm

jbodango wrote:Upon completion or closer to a non-beta release, would it be possible to write up a MIDI sync facts section?
Yes, it would be useful to have a technical document about the intended behavior.

As I understand it now, the tempo change delay would compromise the synchronization.
If the master tempo is increased Live will run behind, and if decreased Live will run ahead.

Or maybe just the tempo display is delayed?

ark
Posts: 1349
Joined: Thu Feb 26, 2009 4:25 pm
Location: New Jersey, USA
Contact:

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by ark » Tue Jun 14, 2011 5:13 pm

Frankly, neither 8.2.2 nor 8.2.4b2 does a particularly good job of tracking rapid tempo changes. I don't understand the problem deeply enough to know whether a solution is even possible.

broc
Posts: 1151
Joined: Mon Jul 26, 2004 8:37 am

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by broc » Wed Jun 15, 2011 9:15 am

Keep in mind that midi clock was designed for hardware devices with zero delay and jitter.
For software in context of general purpose operating systems it will never work perfectly.
Strictly speaking from this view midi clock is an obsolete technology.

phazed
Posts: 39
Joined: Tue Jun 23, 2009 3:20 pm
Location: Cologne, Germany
Contact:

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by phazed » Wed Jun 15, 2011 10:23 am

There is no MIDI hardware device with zero delay and jitter.

chapelier fou
Posts: 5188
Joined: Mon May 15, 2006 12:15 pm

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by chapelier fou » Wed Jun 15, 2011 10:59 am

phazed wrote:There is no MIDI hardware device with zero delay and jitter.
http://www.innerclocksystems.com/New%20 ... %20LE.html
MacBook Pro 13" Retina i7 2.8 GHz OS 10.13, L10.0.1, M4L.
iMac 27" Retina i5 3,2 GHz OS 10.11.3 L10.0.1 M4L.

luddy
Posts: 791
Joined: Sat Aug 08, 2009 3:36 am
Location: Beijing
Contact:

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by luddy » Wed Jun 15, 2011 12:25 pm

Just thinking out loud here (I really like Live, etc., not meant to be any kind of bash).

MIDI Clock is really designed for the situation where two devices are holding identical tempo maps, and the pulses simply tell the slave where the "edges" of the clock are. That is, it was never (ever) meant to communicate tempo changes. If you think about it, it's simply impossible, because you can't even guess the tempo until at least the second tick of a beat at the new tempo, but by that time the slave is already necessarily a little bit out of sync.

I don't know why (maybe there's a really good reason) Ableton doesn't simply write a little network protocol that sends the absolute tempo value out (along with ticks for the actual beats within a bar, or whatever other information) over UDP on some port every so many milliseconds. The slave could read it in. The new tempo value would get there as early as possible, modulo network delays, and there would be no guesswork about the value. If the Live API let you control the tempo via an API call, you could easily rig this up in M4L with a udpsend/udpreceive thing and an interface call or two. It would be far from perfect but so much better than trying to reverse-engineer the tempo from MIDI clock ticks. Of course, that's only for the case of synching two Live rigs, but as I say, no one I ever heard of tried to use MIDI clock to sync dynamically-changing tempos between two pieces of hardware in the old days. I had a bunch of hardware sequencers, etc., and I never heard about any such thing. It is simply because Live has such freedom with tempos that the whole question comes up in the first place IMO.

-Luddy

Paradigm X
Posts: 69
Joined: Fri Jan 01, 2010 2:41 pm

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by Paradigm X » Wed Jun 15, 2011 4:01 pm

Is there any improvement in Ableton as master?

I have read extensive thread son here about this, and appreciate its hit and miss; some people have no issues, and some have loads.

Unfortunately im in the second group :(

I have a tr909, 2x x0xb0x and a rs7000 i sync, coming off 3 midi outs from my PC (one x0x is thru'd off the first). Sync is really quite bad, noticeably out of time. I dont think its my computer as cubase works a lot better.

Cheers
Q6600 : 4gb corsair : 3x 320gb seagate drive 1x 1TB WD Caviar Black : Abit AB9 Pro Mobo : Focusrite Pro 24 DSP : 1xUAD2 Quad, 1xUAD2Duo : Windows 7 x64 : Novation Remote Zero SL : Novation Launchpad : NI Komplete 5 : Cubase 5.5.1 : Ableton 8.1.5

stuartm
Posts: 103
Joined: Fri Apr 23, 2010 1:22 pm

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by stuartm » Fri Jun 17, 2011 7:13 pm

I've noticed a major improvement in an area which was troubling me before when using Live as MIDI clock slave:
Third-Party PlugIn Tempo-synched effects, especially delays.

With the earlier versions (8.2.2 as reference here for me) when using for example impOSCar or V-Station with their internal synched delays, there was audible glitching / jittering in the delay , as if the delay line was constantly changing delay length due to variations in the reported master tempo.
With the new slave algorithm, this is mostly gone and the delays run smoothly. I like that :-)

/update: also tested with Zebra2, same effect (heavily glitched delay in 8.2.2 slave, smooth delay in 8.2.4b2 slave)

There is a certain lag in tempo adaptation when changing the BPM abruptly, from say 140BPM to 100BPM it's about 3-4 seconds before it's in sync again.
However, when ramping the tempo up/down more, it's not very noticeable, and thus usable (for me).
I also concur with the statement that a smooth clock slave is preferable over a highly reactive one.
Paradigm X wrote:Is there any improvement in Ableton as master?
No, it's only the slave algorithm.

stuartm
Posts: 103
Joined: Fri Apr 23, 2010 1:22 pm

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by stuartm » Mon Jun 20, 2011 7:40 pm

Update: there's stll some odd behaviour, incl. when swiching to external sync, i.e. clicking the "ext" button in the tempo area.

Given that an external MIDI clock is constantly running and sending clock to Live:

"ext" is on, Live is running as slave
then load a new set -> when the set is loaded, it immedeately start running (right tempo, but not in sync)
Also, switching off/on the "ext" does not help, because as soon as it's on again, Live starts running

Before, a MIDI start signal was needed to start Live as slave (in sync).
I don't imagine this was changed on purpose ?

/edit:
just to keep this up to date: this issue has been filed as a bug by Ableton support

Paradigm X
Posts: 69
Joined: Fri Jan 01, 2010 2:41 pm

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by Paradigm X » Wed Jun 29, 2011 11:02 am

Well, i know it wasn't supposed to help, but just thought Id report that going from 8.1 to 8.2.4b1 has really improved master sync for me as well :? :D

Ableton was rock solid last night clocking two x0xen, RS7000 and 909... never had it so good.

Maybe something in 8.2 fixed it? I missed that update. Or just some weird issue i had thats mysteriously fixed?

Who knows.

Anyway, nice one :) Not tried ableton as slave yet, too many midi cables everywhere :lol: :mrgreen:
Q6600 : 4gb corsair : 3x 320gb seagate drive 1x 1TB WD Caviar Black : Abit AB9 Pro Mobo : Focusrite Pro 24 DSP : 1xUAD2 Quad, 1xUAD2Duo : Windows 7 x64 : Novation Remote Zero SL : Novation Launchpad : NI Komplete 5 : Cubase 5.5.1 : Ableton 8.1.5

Alibra
Posts: 53
Joined: Tue Apr 05, 2011 1:20 am
Location: Orange County, CA
Contact:

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by Alibra » Wed Jul 13, 2011 5:19 pm

chapelier fou wrote:For me what's important in syncing two computers is precisely to work well for tempo changes... If the tempo remains the same, i don't see the point of syncing the computers, unless for start/stop, which is usually doable by hand.
Once i got into the hang of syncing, I found it much better because not only is the tempo pretty much the same, but both computers are on the same count. When we tried without syncing, we would always be off a little. One thing I'd love though, is to have the ability to save the tracks from both computers as one track. Not sure if that's possible though.
Calvinalibra
APC40 + Push + Apogee Duet 2
Ableton + Maschine
To Self: Learn the equipment you have before you spend a bunch of money on new stuff. New equipment doesn't make you better <-- not working out for me.

Per Boysen
Posts: 1057
Joined: Sat Aug 30, 2003 4:11 pm
Location: Sweden
Contact:

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by Per Boysen » Wed Jul 13, 2011 6:14 pm

[nis] wrote:There is, however, also a small disadvantage: Whilst the new algorithm works great at a constant tempo, it now reacts slightly slower to tempo changes.
Yikes! Tempo Changes In Performance is kind or the reason for using sync in my book :-)) Just like member gtodd876 I run Live as MIDI Clock slave to the Looper/Real-Time sampler Mobius hosted by Live as a plugin - clock sent through the MBP's IAC Bus. This works perfect now in 8.2.2 but five years ago I had to abandon Live because Live lost sync so often during my concerts. I first rebuilt my rig in Bidule and later on in Mainstage, but now I have come back to Live because 8.2.2 sounds so good and seems so CPU efficient. I really like 8.2.2 and I don't mind at all if Live's slave position syncing up is slower. On the contrary I think it can sound cool if a sync slave needs a couple of seconds to catch up with a sudden tempo change (think about how cool the Repeater sounded doing this!).

Bottom line:
Please make sure Live does sync up - no matter if it is a slow procedure - so it just don't fires of that dumb "sync lost" msg while doing nothing.

Suggestion:
Why not implementing a "Search Sync" function that we may assign to a foot pedal! Or maybe even a "Search And Re-establish Sync If Lost" function?

Bottom Line of Bottom Lines:
A bit whailing while re-estblishing sync lock is not bad - but loosing sync is ULTIMATELY BAD!!!
Greetings from Sweden

Per Boysen
http://www.perboysen.com

pepezabala
Posts: 3499
Joined: Mon Jun 07, 2004 4:29 pm
Location: In Berlin, finally

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by pepezabala » Wed Jul 13, 2011 6:22 pm

Anyone tried looper on a slaved Live? I had ugly artifacts and freakouts of the looper device on a slaved Live and stopped using sync mainly because of this. But if this works better now I will try again.

Per Boysen
Posts: 1057
Joined: Sat Aug 30, 2003 4:11 pm
Location: Sweden
Contact:

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by Per Boysen » Wed Jul 13, 2011 6:31 pm

pepezabala wrote:Anyone tried looper on a slaved Live? I had ugly artifacts and freakouts of the looper device on a slaved Live and stopped using sync mainly because of this. But if this works better now I will try again.
Yes, I tried it and it sucks. Not just in Live. I stay away from even step sequencers running inside a slave syncing host application. Effects I use though - that works like a charm - are LFOs to drive plugin parameters, beat depending delays and tremolo stuff etc.

Loopers in general need to spin freely, if you mash stuff up for a show, so syncing the host application is definitely the way to go. If you let Live's Looper be the master ("set tempo") I guess it will work better?
Greetings from Sweden

Per Boysen
http://www.perboysen.com

Per Boysen
Posts: 1057
Joined: Sat Aug 30, 2003 4:11 pm
Location: Sweden
Contact:

Re: MIDI clock (slave) improvements in Live 8.2.4b1

Post by Per Boysen » Wed Jul 13, 2011 6:45 pm

stuartm wrote:There is a certain lag in tempo adaptation when changing the BPM abruptly, from say 140BPM to 100BPM it's about 3-4 seconds before it's in sync again.
That's peanuts! As long as sync is not lost I can live with such a lag :)
Greetings from Sweden

Per Boysen
http://www.perboysen.com

Post Reply