general: midi vs. live lom - timing issues
Jun 08 2014 | 5:25 pm
hi there,
i've been struggling with this general problem for a while and thought i'd pop it into the community to see if i'm doing something very general wrong in my patches.
1) let's say i have a track with a midi-clip on it.
2) this midi-clip has a note on its first count of its first bar.
3) i've written a patch that does "something" (e.g. turn off an effect) when ever a new clip is launched
4) problem: the midi-note is a little "quicker" than the trigger action
5) result: the effect is activated slightly after the first note is played. this is audible (and annoying).
has anybody experienced something similar? seems to be a general issue (for my case at least)
- Jun 08 2014 | 8:31 pmIt's a general issue: the Live API doesn't provide 100% accurate timing.
- Jun 08 2014 | 8:39 pmthanks broc. for my observation, the live api actually provides 100% inaccurate timing. the delay (i mentioned in point 5) occurs without any exception, and to me it appears to also always be the same. do you by any chance know if it might be the case that the latency of the api is not a "floating" inaccuracy but rather a sort of fixed timing-delay (such as *guess* precisely 2ms.. dunno)? because then i might see a chance to compensate it (with a different approach).
- Jun 08 2014 | 9:21 pmAs I understand it, latency is due to the fact that the Live API runs on low-priority threads. So it probably depends on the actual Live set, i.e. other activities with high priority like midi or audio processing.Unfortunately there is no official documentation about the Live API timing behaviour.
- Jun 08 2014 | 9:23 pmmh.. that's to bad. thanks for your help, broc!
