m4l delay compensation bug . Can i get the audio buffer size of live?
The [adstatus] object doesn't help in m4l. can this be done with other objects?
the problem is: midi generated by a m4l device recorded into a clip on another midi track is shifted forward due to an latency compensation error/bug? (this is smelling) i could work around if i had the exact value which seems to be the size of the audio buffer. O.
broc?
i found an older post in the archive
I think automatic measuring would be difficult but you can estimate it. The global latency is determined by the track that contains a chain with the highest number of M4L devices. Each device added to that chain will add to global latency by an amount proportional to audio buffer size.
that sounds doable if i had the buffer size..
the vector size should be always 32, but i dont think the midi latency issue (only) comes form that.
The audio buffer of Live can be set set in the preferences, range 14-2048 samples.
But unfortunately the actual value is not accessible in M4L devices.
Also, Live's PDC is incomplete, i.e. not applied to automation and synced devices.
Try this.
A) create a Live set with 2 midi tracks. On the first track put an M4L midi device containing live.step that generates notes on the beat, and record the notes into a clip of the second track: the clip notes will appear exactly on the beat.
B) now insert an empty M4L midi device in front of the live.step device and record again into a clip of the second track. In this case the recorded notes will appear early on the clip.
It happens because the synchronisation of M4L devices (eg. live.step) is not automatically compensated according to their latency in the device chain, a flaw of Live's PDC.
Please tell me they at least think about how to get over this limitations at Ableton and Cycling.
The most logical thing would have been a way to insert a max midi effect between Input and Clip.
Of course we want to alter the Midi IN, that is where the really awesome devices would live.
ok, by ableton design all devices sit after the clip. And than there's this big hidden bummer if you record max midi on another track? I'm upset. I will not accept it. How can you even release m4l with this compensation problems under the hood.
Bringing no attention of new users to this problem causes many useless working hours until they hitting the wall.
It's time to enlarge the sandbox or i cut a hole into the fence around it. haha
The limitations of PDC are mentioned in the Live manual and have been discussed extensively on the Ableton forums. But as I understand it, substantial improvements would be difficult to implement.
Of course the problems should be brought more clearly to attention of M4L users, in particular the simple fact that M4L devices introduce latency (like any 3rd party plugins) and thus the timing may be affected due to limitations of Live's PDC.
broc, i did some testing and can you confirm that as long as the max device is alone in it's track,
midi is correctly send to another track EVEN if m4l devices exist on other tracks?
because i think i scrambled it with your quote that the chain with the most m4l devices in it will determine the latency. i think that has nothing to do with my problem.
for the test device to be recorded properly, the only requirement seems to be that it is the only max device in its track. not related to the number of max devices in the rest of the live set.
> for the test device to be recorded properly, the only requirement seems to be that it is the only max device in its track. not related to the number of max devices in the rest of the live set.
Yes. More precisely, the synced test device must be the *first* device in its track (possibly followed by other non-synced m4l devices). Since the first device has no latency it runs in perfect sync with Live's transport.
ok then i have to partly withdraw from what i wrote because of missunderstanding. recording of synced midi note output of a max device works reliably under this condition. i can live with that for now. thanks broc