Ableton Forum

deva wrote:

davepermen wrote:
and the vote does not represent anything meaningful.

and if 10 out of 200 voted to fix sync, you would say otherwise...

no. as said, i did vote myself for fix sync. but the problem is, the way it's setup, nothing else actually really makes sense to vote. because even those that don't have any problems with it all want it to be fixed (like me). why? because there could be the day where it suddenly is a problem.

andydes wrote:Davepermen: Although I agree with you a about 3Phase's attitude, trying to get him to stop isn't going to work, and by continually raising the issue, you're making yourself look just a bad. I know it's hard when he's using offensive nicknames and the like, but is it really worth the hassle?

yeah, worth it, totally. reasons:
1) from time to time we then refocus on the actual issue, which is a big + for anyone.
2) he gets to know that he should not just get away with it. bad behaviour does not deserve acception.

but mainly 1) is what i am interested in. 2) is just for the angry fairness part of me.

and as you see, in all this discussion, nice things pop up all the time. so yeah, it's definitely worth discussing. for raising awareness (what matters for 3phase), and for learning (what matters for me). it can be wild, it can be terribly annoying. but in the end, we all profit something from it.

and maybe, one day, he can actually spell my name..

When you see how much producers of tape machines and record decks care about wow and fluter i think we need to be in the 0.0x bpm area at least, and this only when necessary..so at least with wordclock it should be without tempo changes, just 0.00 fluctuatation on matching tempos

especially because theese mac machines are really the best regarding internal miditiming..
and as it looks now that also only applies to the actual models..

ok.. maybe you can do another test with the 15 inch as master..this way you know if that can make things better for the 13 inch and if the older mac books have in general the worse performance i am experiancing..
what would suggest a laptop change for me...

3phase wrote:one other observation..when beeing in EXT sync mode..its is possible to switch that off and your slave just runs allong with out iteruption.. great

but.. siwtching it on while running again even on the wordclocked sytem causes a glitch that allmost sets the slave in the offbeat.

Interestingly also, Live responds to MIDI clock Start and Stop commands even if no clock messages are sent. This can be checked by sending a MIDI clock master through eg. MidiPipe (on Mac) and filtering out the clock messages. In this case Live as slave will just start and run on its own tempo.

But it should be noted that this behavior does not conform to the MIDI standard:

MIDI Start is just a warning to let the slave know that the next MIDI Clock represents the downbeat, and playback is to start then.

broc wrote:

3phase wrote:one other observation..when beeing in EXT sync mode..its is possible to switch that off and your slave just runs allong with out iteruption.. great

but.. siwtching it on while running again even on the wordclocked sytem causes a glitch that allmost sets the slave in the offbeat.

Interestingly also, Live responds to MIDI clock Start and Stop commands even if no clock messages are sent. This can be checked by sending a MIDI clock master through eg. MidiPipe (on Mac) and filtering out the clock messages. In this case Live as slave will just start and run on its own tempo.

But it should be noted that this behavior does not conform to the MIDI standard:

MIDI Start is just a warning to let the slave know that the next MIDI Clock represents the downbeat, and playback is to start then.

? is it ? i am not aware in anything in the midi standard that says that the sart command only can be execcuted on an external clock.. but maybe there is.. havent had the technical paper in the hand for at least 15 years...

but its an intersting thing to try out..on remote start comands to the screen conrols its not possible to achive sync start..at least not on my two mac laptops.. they are up to 10 ms out of each other, just randomnly different on each start..so not usable.. but maybe it works better via the midiclock start command...

synced remote start woud be a great sync option too..and probably easy to achive..

if ableton would polish all this kind of bad working details and allow such non standard operations like getting start commands and clock from differnet sources live could be really the swiss army knife for sync questions...

3phase wrote:maybe you can do another test with the 15 inch as master..this way you know if that can make things better for the 13 inch and if the older mac books have in general the worse performance i am experiancing

that's on my to-do list for today only have access to a mbp-15 and the mb so it'll be a scaled down test with the mb as slave. will post results later....and yes, i'll test at 125bpm and higher although we're more downtempo folks

tchan wrote:

3phase wrote:maybe you can do another test with the 15 inch as master..this way you know if that can make things better for the 13 inch and if the older mac books have in general the worse performance i am experiancing

that's on my to-do list for today only have access to a mbp-15 and the mb so it'll be a scaled down test with the mb as slave. will post results later....and yes, i'll test at 125bpm and higher although we're more downtempo folks

im turning into a down dempo folk to ... 117 is fast allready.. .)

ran into some networking issues (see notes) but managed to get detailed notes on two separate tests. very interesting results...

10.09 SYNC TEST A

Setup:

master: macbook pro-15, 2.4ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, jazzmutant lemur (mu patch), motu 828 mk2 interface

slave: macbook, 2.16ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, monome 128, iPad (griid control app), apogee duet interface

Setup Notes:
- all laptops and iPad connected to the same ad hoc wifi network
- laptops synced using network core midi in osx
- both live sessions had a sample rate of 44.1khz w/ buffer setting of 128 samples

Sync Results (variable tempos, duration = 575 bars)

[1] 70bpm > bar 0 - 100
mb (slave): tempo fluctuation from +/- .02 to 0.12bpm

[2] 110bpm > bar 100 - 165
mb (slave): tempo fluctuation from +/- .07 to 0.40bpm

[3] 125bpm > bar 165 - 262
mb (slave): tempo fluctuation from +/- .06 to 0.54bpm

[4] 140bpm > bar 262 - 488
mb (slave): tempo fluctuation from +/- .03 to 0.59bpm

[5] 70bpm > bar 488 - 575
mb (slave): tempo fluctuation from +/- 0 to 0.12bpm


Test Notes:
- more good results from wireless clock sync, everything sounded tight
- ran another test and found it wasn't too bad to disengage from slave mode, load up a new project and sync back to the master > after restarting the master clock, the slave machine doesn't output sound until one bar has passed (tracks appear to be muted) > however both clocks are synced


10.09 SYNC TEST B

Setup:

master: macbook pro-15, 2.4ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, jazzmutant lemur (mu patch), onboard audio

slave 1: macbook, 2.16ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, onboard audio

slave 2: powerbook-15, 1.67ghz powerpc g4, osx 10.5.8, live 7.0.14, onboard audio

Setup Notes:
- laptops connected to a home wifi network on a linksys wrt54gl router with a shared internet connection
- the powerbook would continually drop the connection to the ad hoc midi network > after an hour of fiddling with network & airport settings i decided to use a router and now the powerbook stayed connected
- decided to do a quick & dirty test with just the laptop's onboard audio

Sync Results (variable tempos, duration = 280 bars)

[1] 70bpm > bar 0 - 61
mb (slave 1): tempo fluctuation from +/- .02 to 0.13bpm
pb (slave 2): tempo fluctuation from +/- .02 to 0.16bpm

[2] 125bpm > bar 61 - 165
mb (slave 1): tempo fluctuation from +/- .02 to 0.40bpm
pb (slave 2): tempo fluctuation from +/- .04 to 0.58bpm

[3] 140bpm > bar 165 - 280
mb (slave 1): tempo fluctuation from +/- .03 to 0.48bpm
pb (slave 2): tempo fluctuation from +/- .03 to 0.48bpm


Test Notes:
- great results...and the powerbook's timing was especially surprising!
- was only using the onboard laptop speakers but everything sounded like it was in sync, no glitches during tempo changes
- seems like a router can be useful to connect older laptops and improve timing results > time to invest in an airport express base station for the stage

tchan wrote:ran into some networking issues (see notes) but managed to get detailed notes on two separate tests. very interesting results...

10.09 SYNC TEST A

Setup:

master: macbook pro-15, 2.4ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, jazzmutant lemur (mu patch), motu 828 mk2 interface

slave: macbook, 2.16ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, monome 128, iPad (griid control app), apogee duet interface

Setup Notes:
- all laptops and iPad connected to the same ad hoc wifi network
- laptops synced using network core midi in osx
- both live sessions had a sample rate of 44.1khz w/ buffer setting of 128 samples

Sync Results (variable tempos, duration = 575 bars)

[1] 70bpm > bar 0 - 100
mb (slave): tempo fluctuation from +/- .02 to 0.12bpm

[2] 110bpm > bar 100 - 165
mb (slave): tempo fluctuation from +/- .07 to 0.40bpm

[3] 125bpm > bar 165 - 262
mb (slave): tempo fluctuation from +/- .06 to 0.54bpm

[4] 140bpm > bar 262 - 488
mb (slave): tempo fluctuation from +/- .03 to 0.59bpm

[5] 70bpm > bar 488 - 575
mb (slave): tempo fluctuation from +/- 0 to 0.12bpm

ok..the macbook is not as good as the newer ones.. but you still seem to have much better values--
however at one point you get to 0.5 bpm with is again close to the 0,7 i have..

question is how often is it going this far off? rarelly or within any bar?

on my machine there are sometimes a bit more stable runs but in general its doing all the time the up and dow dance..

the distribution of the error in your test is intersting as well ..that it gets better after a while gain. probaly some random factors and the next day its different again?

i think the test results would be more meaningful if i could actually calculate the mean value of the tempo fluctuations. as nico stated earlier, live recalculates the tempo on the slave machines every 48 clock ticks/half bar. so you can imagine it's quite a challenge - and not very precise - eyeballing the constantly changing tempo readings and marking down the values by hand. all i did was present the range of values in my test results.

but let me be clear:
a) the tempo of the slave machines changes every half bar; the value goes up and down like a yo-yo!
b) the fluctuations are highly variable; you would need some sort of application to capture the timing information and to crunch the numbers to see if there's a pattern
c) the fluctuations are not material enough to affect the audio; everything sounds like it's in time

personally i don't think you need the latest & greatest laptop to improve sync performance. after all, i got great sync results from a 5 year old powerbook g4! besides, apple introduced network midi with osx10.4 about 5 years ago...seems reasonable to conclude that any hardware released during that time would be capable of handling network midi.

perhaps check your wireless network? try connecting via ad hoc and compare performance with a router. in our case, i'm definitely getting an airport express base station for performance situations. still, it's encouraging to know that in a worse case scenario, you can get great sync simply using a peer-to-peer wifi connection

3phase wrote:i wonder if it wouldnt be very nice and usefull when the slave just smoothly adjusts to that external clock but keeps his actual timing offset up to the next restart event..this way one can prepare for slave operation by switching the EXT button without damaging the performance and the straight resyncing only happens on the next restart..this way the slave operator can decide itself at any time to get out of his slavery and back in without damage to the performance..after having ensalved himself again he might request a restart from the master..

with song position pointer / song mode clock that could be even enhanced to a point where a user might load another projekt..switches the ext button and gets auto started at the next syncpoint without having the master restarted..

this is an awesome idea for a group performance situation! i'd also like to suggest another option to achieve this...once the slave operator loads the new project and enables EXT sync, maybe the master operator can send a restart command that's tied to the global quantize value? similar to triggering a clip except you're restarting the clock. this way, the restarts are more smooth and in time. right now, it gets kinda glitchy when i restart all the laptops.

it would also be awesome if everyone on the midi network can seamlessly take turns being the master and slave clock. this way, it's easier for people to load new projects and sounds...perhaps limiting our need to create ridiculously over-bloated projects with hundreds of scenes

hehe...i'm hoping these suggestions can evolve into a new feature set centered around group sync..."live band mode"

tchan wrote:ran into some networking issues (see notes) but managed to get detailed notes on two separate tests. very interesting results...

10.09 SYNC TEST A

Setup:

master: macbook pro-15, 2.4ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, jazzmutant lemur (mu patch), motu 828 mk2 interface

slave: macbook, 2.16ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, monome 128, iPad (griid control app), apogee duet interface

Setup Notes:
- all laptops and iPad connected to the same ad hoc wifi network
- laptops synced using network core midi in osx
- both live sessions had a sample rate of 44.1khz w/ buffer setting of 128 samples

Sync Results (variable tempos, duration = 575 bars)

[1] 70bpm > bar 0 - 100
mb (slave): tempo fluctuation from +/- .02 to 0.12bpm

[2] 110bpm > bar 100 - 165
mb (slave): tempo fluctuation from +/- .07 to 0.40bpm

[3] 125bpm > bar 165 - 262
mb (slave): tempo fluctuation from +/- .06 to 0.54bpm

[4] 140bpm > bar 262 - 488
mb (slave): tempo fluctuation from +/- .03 to 0.59bpm

[5] 70bpm > bar 488 - 575
mb (slave): tempo fluctuation from +/- 0 to 0.12bpm


Test Notes:
- more good results from wireless clock sync, everything sounded tight
- ran another test and found it wasn't too bad to disengage from slave mode, load up a new project and sync back to the master > after restarting the master clock, the slave machine doesn't output sound until one bar has passed (tracks appear to be muted) > however both clocks are synced


10.09 SYNC TEST B

Setup:

master: macbook pro-15, 2.4ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, jazzmutant lemur (mu patch), onboard audio

slave 1: macbook, 2.16ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, onboard audio

slave 2: powerbook-15, 1.67ghz powerpc g4, osx 10.5.8, live 7.0.14, onboard audio

Setup Notes:
- laptops connected to a home wifi network on a linksys wrt54gl router with a shared internet connection
- the powerbook would continually drop the connection to the ad hoc midi network > after an hour of fiddling with network & airport settings i decided to use a router and now the powerbook stayed connected
- decided to do a quick & dirty test with just the laptop's onboard audio

Sync Results (variable tempos, duration = 280 bars)

[1] 70bpm > bar 0 - 61
mb (slave 1): tempo fluctuation from +/- .02 to 0.13bpm
pb (slave 2): tempo fluctuation from +/- .02 to 0.16bpm

[2] 125bpm > bar 61 - 165
mb (slave 1): tempo fluctuation from +/- .02 to 0.40bpm
pb (slave 2): tempo fluctuation from +/- .04 to 0.58bpm

[3] 140bpm > bar 165 - 280
mb (slave 1): tempo fluctuation from +/- .03 to 0.48bpm
pb (slave 2): tempo fluctuation from +/- .03 to 0.48bpm


Test Notes:
- great results...and the powerbook's timing was especially surprising!
- was only using the onboard laptop speakers but everything sounded like it was in sync, no glitches during tempo changes
- seems like a router can be useful to connect older laptops and improve timing results > time to invest in an airport express base station for the stage

looks to me that the faster tempo you go, the less sync you get.
bad news for people like me then whos usually over 200 bpm -.-

friend_kami wrote:

tchan wrote:ran into some networking issues (see notes) but managed to get detailed notes on two separate tests. very interesting results...

10.09 SYNC TEST A

Setup:

master: macbook pro-15, 2.4ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, jazzmutant lemur (mu patch), motu 828 mk2 interface

slave: macbook, 2.16ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, monome 128, iPad (griid control app), apogee duet interface

Setup Notes:
- all laptops and iPad connected to the same ad hoc wifi network
- laptops synced using network core midi in osx
- both live sessions had a sample rate of 44.1khz w/ buffer setting of 128 samples

Sync Results (variable tempos, duration = 575 bars)

[1] 70bpm > bar 0 - 100
mb (slave): tempo fluctuation from +/- .02 to 0.12bpm

[2] 110bpm > bar 100 - 165
mb (slave): tempo fluctuation from +/- .07 to 0.40bpm

[3] 125bpm > bar 165 - 262
mb (slave): tempo fluctuation from +/- .06 to 0.54bpm

[4] 140bpm > bar 262 - 488
mb (slave): tempo fluctuation from +/- .03 to 0.59bpm

[5] 70bpm > bar 488 - 575
mb (slave): tempo fluctuation from +/- 0 to 0.12bpm


Test Notes:
- more good results from wireless clock sync, everything sounded tight
- ran another test and found it wasn't too bad to disengage from slave mode, load up a new project and sync back to the master > after restarting the master clock, the slave machine doesn't output sound until one bar has passed (tracks appear to be muted) > however both clocks are synced


10.09 SYNC TEST B

Setup:

master: macbook pro-15, 2.4ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, jazzmutant lemur (mu patch), onboard audio

slave 1: macbook, 2.16ghz core 2 duo, osx 10.6.4, live 8.2, max for live 5.1.5, onboard audio

slave 2: powerbook-15, 1.67ghz powerpc g4, osx 10.5.8, live 7.0.14, onboard audio

Setup Notes:
- laptops connected to a home wifi network on a linksys wrt54gl router with a shared internet connection
- the powerbook would continually drop the connection to the ad hoc midi network > after an hour of fiddling with network & airport settings i decided to use a router and now the powerbook stayed connected
- decided to do a quick & dirty test with just the laptop's onboard audio

Sync Results (variable tempos, duration = 280 bars)

[1] 70bpm > bar 0 - 61
mb (slave 1): tempo fluctuation from +/- .02 to 0.13bpm
pb (slave 2): tempo fluctuation from +/- .02 to 0.16bpm

[2] 125bpm > bar 61 - 165
mb (slave 1): tempo fluctuation from +/- .02 to 0.40bpm
pb (slave 2): tempo fluctuation from +/- .04 to 0.58bpm

[3] 140bpm > bar 165 - 280
mb (slave 1): tempo fluctuation from +/- .03 to 0.48bpm
pb (slave 2): tempo fluctuation from +/- .03 to 0.48bpm


Test Notes:
- great results...and the powerbook's timing was especially surprising!
- was only using the onboard laptop speakers but everything sounded like it was in sync, no glitches during tempo changes
- seems like a router can be useful to connect older laptops and improve timing results > time to invest in an airport express base station for the stage

looks to me that the faster tempo you go, the less sync you get.
bad news for people like me then whos usually over 200 bpm -.-

just go on halfspeed.. its probably anyway rather your real speed because over 200 is unrealistic..

you probably use 8th notes to play 16th..

keep in mind that all this superfast 1920 swing and foxrtrott stuff is usually below 100 bpm.

so..speed is pretty relativ..

broc wrote:

3phase wrote:one other observation..when beeing in EXT sync mode..its is possible to switch that off and your slave just runs allong with out iteruption.. great

but.. siwtching it on while running again even on the wordclocked sytem causes a glitch that allmost sets the slave in the offbeat.

Interestingly also, Live responds to MIDI clock Start and Stop commands even if no clock messages are sent. This can be checked by sending a MIDI clock master through eg. MidiPipe (on Mac) and filtering out the clock messages. In this case Live as slave will just start and run on its own tempo.

But it should be noted that this behavior does not conform to the MIDI standard:

MIDI Start is just a warning to let the slave know that the next MIDI Clock represents the downbeat, and playback is to start then.

its a pretty interesting question here how live starts to run in sthe absence of an external clock...

does this say that lives internal clock is runnig permanently?

and if this is the case.. the moment you send the start command relates to the momet of the actual start just how that is realted to the free running internal clock.. so the actual moment of start execution can vary to the amount of time between the single clockticks?

ok.. that could explain the eratic start behaviour when beeing in free sync aswell..

and if its working as such i would say a reset of such a internal clockcycle on a start command should be executed. but thats specualtion of cause..


I any case is this nehaviour of ableton live a possible and easy syc tactics for wordclocked systems..

just have the clock filter iternal.. propperly reset and offset the interal clock o such a start command to provide real sync start.. and free running live machines can be synced without much effort.

This also might better the situation for dj sync when the start perfomance of live as tempo master gets more precise..

And one more sync related feature wish..

this time for the szeario that i sync to the clock generated by a dj software..
Traktor for example..

and as i had ti find out at the weekend..there are dj´s that refuse to dj with ableton live and prefer traktor.. so it would be ice to able to play with theese guys aswell..

the way to sync to them would need..

i can switch to ext mode without getting my ableton live runnig,,

the ext clock is taken..and dejittred...

and on top of that i can execute a manula start stop AND nudging..but the nudging is adjusting the offset delay instead of the tempo

so oposite to just start synchronisation a pure tempo synchronisation with maual start...

Ok..
thats quite a lot of wishes..
But wouldnt it be great when your main software would be able to dela with any syncszenario?
And wouldnt be even greate r when you could cahnage that options while running and be able to restart yourself in time at any point ?

allowig others to restarrt you.. or beieng able to prohibit that?

and maybe even having an resync button like in traktor when this external start command filtering made you miss an important restart.. or just to quickly fixes the situatio?

so in case of having disabled ext start commands Liv is memorizing the last recived startcomad and is able to recall and resync acording to that position at wish any time regardless what tempo mess the user might have created in between?

wouldt that be nice? and allowing to enter a synced system without bothering allready involved with restart requests or alike?

To fix the sync issues of ableton live of cause we mainly need a more stabe external clock reading..
thats for sure

but really fixing the sync issue.. independent of the individual paltform performance one really would need to go a step further and deliver something liike a package of sync and resync options..

well designed that might be realizable with not too much effort and control elements with a semi intteligent automatic..
we need a resync button.. that acording to the mode of operation works differently...
ad a mode of operation for the different clock sycing algos like standard...only start sync.. manual Start&tempo sync..

In master mode that resync button would sends a restart comand to the salves on the next one...

So not so really much more than just fixing the clock management..
a set of start message handlings together with that ..and we have a pretty comprehensiv toolbox to face a wide range of clock sync situations..

the important step forward would be to manage resync/restart at any time while running...

the world of tomorow..go for it