Best method for tight syncing to Live transport in M4L
Hello.
I have tried a few methods for syncing to lives transport but they all seem to have timing problems. Locked Phasor toedge, metro at 16n or ticks, reading the ticks from an observed transport but all seem to be very loose when connected to a counter. It always seems to need a few restarts in order to lock in. Once it is locked it is usually okay but then when I restart I have to do it again.
Does anybody have a sure fire way for tight sync to Live transport. Just something simple that I can re-use.
Thanks
you want ableton to be the master? what are you syncing?
plugsync~ ?
I want Ableton to be the master. I am creating sequencers in M4L and sending it out but I seem to have a lot of problems with timing. It just seems sloppy. I was wondering if somebody could post a method of slaving M4L's [counter] to lives transport. I can do it but it tends to be sloppy. I wonder what other people do to get tight timing.
Alfonso I'll try plugsync~.
Basically, plugsync~ allows sample accurate synchronization.
I'm using it to build counters for any bar division in the range 1-128.
Thanks for the patch Broc... I'll check it out later when I am on my computer. I am using it to make a Lemur controlled sequencer/processing device for the AcidLab Miami 808 clone... so tight timing is important.
I made the guts of the drum sequencer (patterns from a list, accents, repeats with vel sen). The timing is a lot better. Cheers.
I wonder would anybody have any idea's how to get swing on to it. I usually use the old delay bang trick, it's simple but it's never great.
hey, i'm trying to achieve about the same thing with a 'metro 16n @active 1 @quantize 16n' together with a counter object to create a sequencer.
I'm running into the same sync problems when the counter is enabled. Did you ever got it right?
I think this is a Ableton Live bug. And in my opinion very critical.
It seems by default everything is instantiated in 4/4, if the music is always in this time signature no one will ever notice this problem. But there is very easy steps to recreate this problem, and all objects that lock to the transport seems to fail: plugsync~, transport, phasor~, etc, etc.
1) Changing time signature somewhere in the middle of the bar (with markers or manually);
2) Dropping your device at some point in the middle of the sequence/bar with a time signature different from 4/4;
3) start playing in the middle of a bar after dropping the device, more or less the same as previous;
*Usually everything resets when the playhead crosses a time signature marker.
**property resetbarcount from transport turns always off in M4L environment.
The problem seems to be internal to the timing system of Ableton, I don't think there's anything we can do with max patches to solve it.
I hope they address this issue ASAP.
I also feel your pain. I did not find a permanent solution but I did make a quick fix for the initial sync. I would start the live transport and the sequencer at the same time I would feed in a midi channel into the sequencer patch. I would use the difference of two events that would usually be synchronized to delay the signal with pipe 0. 0. once the slight delay is calculated it almost never changes and it's usually a 20ms deviation.
How about using a midi clip as a kind of timecode, fed into your midi sequencer?
Locked phasor~ or plugsync~ should get you there.
No need for any MIDI clip weirdness. I would suspect that MIDI would introduce more timing inconsistencies than doing the synchronization at audio rate within the patch.
If you are changing time signatures/BPMs/dropping devices in the middle of the bar I'm not surprised you'd run into a few timing issues. If you are going to be doing stuff like that, you should build in some systems for handling such cases.
Using midi clips to drive a sequencer is pretty reliable in my experience. Internally, Live's MIDI is sample tight as far as I can tell. Its Max's processing of midi that introduces jitter, and that will also occur whether you're using a phasor~ to drive a midi sequence, or processing midi notes. Live's buffer size should be as small as you can make it, for best timing.
Here's an example of a basic clip driven sequencer. You'll need to play a clip into it of sixteen 1/16th notes, starting from C3 and rising in semitones. This method also allows you to use Live's own swing settings on the clip.
Its Max’s processing of midi that introduces jitter, and that will also occur whether you’re using a phasor~ to drive a
Are they using MIDI at all though? That was never mentioned. They just said they were making a sequencer. It's just as likely that there is 0 midi data at all in their implementation.
Also if you're clocking at 1/16th note, that's a pretty large resolution (especially if this is meant to simulate MIDI clock. That comes at a much faster rate). It just seems silly to use external MIDI clips to synchronize something that can be done completely at audio rate within a patch. Of course if your solution solves the issues of whatever the dude was talking about with changing time signatures etc., then it's a great solution.
OP is making a MIDI sequencer to drive an audio instrument. I was responding to loadmess's complaint about loss of sync upon changing tempo, time sig, dropping mid bar. You can have a clip run not just 1/16ths but at any resolution up to Live's own resolution.
The problems that I've found with locked objects (phasor~ metro etc.) is that it can be confusing when the transport returns to loopstart, to know whether that is because play has looped back to the start (play note) , or whether the playhead has just been moved to the start without transport running (don't play note). I can use something like plugsync~ or M4L.api.ObserveTransport to tell me, but then I have to reset counters in the right order, or I get missed or extra notes. Its possible, and I usually go this route, but it can get confusing sometimes.
If you want to be sure that the notes that come out will definitely play at the same time as notes on your clip under a range of conditions, the clip method is an option, though it has its own problems. You can do other cool stuff easily though, like playing one sequence with another sequence for evolving melodies or drum patterns.