Evan

I am working on a patch that is an MLR type of chopping effect. I have noticed that there is some sort of delay happening between button presses on my launchpad in user 2 mode and live.observer reporting values. I have used the launchpad patch in other devices before, but the timing of presses aren't as important, so I have never noticed this before. Does anyone have any knowledge or advice concerning this topic?

I am working on a patch that is an MLR type of chopping effect. I have noticed that there is some sort of delay happening between button presses on my launchpad in user 2 mode and live.observer reporting values. I have used the launchpad patch in other devices before, but the timing of presses aren't as important, so I have never noticed this before.   Does anyone have any knowledge or advice concerning this topic?


m4l-live-observer-latency

I've done some programming using the Launchpad with instances of live.observer. Launchpad MIDI is quite slow and LiveAPI introduces some latency too, but as long as you don't use Launchpad as an interface for real tight drumming, latency is quite bearable.

Are your computer specs sufficient for the job?

My advise is to carefully go through your patcher and look for any loop that may be iterated too often. Are there many deferlow's in the workflow?

Perhaps you should bring down the patcher to it's absolute minimum and observe latency, then gradually insert more functionality.

I've done some programming using the Launchpad with instances of live.observer. Launchpad MIDI is quite slow and LiveAPI introduces some latency too, but as long as you don't use Launchpad as an interface for real tight drumming, latency is quite  bearable.

Perhaps you should bring down the patcher to it's absolute minimum and observe latency, then gradually insert more functionality.


According to my tests live.observer introduces latency up to 50 ms. It's not designed for accurate timing.

I've definitely experienced latency in my own MLR clone, though it's frustratingly inconsistent. Quantizing button presses can help compensate for latency, though you'll need to set a long enough quantization cycle to accommodate for input and observer lag.

Feel free to have a look at my version of the Live Clip Chopper patch here:

It's monome-centric, but all the machinery for clip chopping is abstracted, and as optimized as I could get it for low latency. I've been using variants of this patch for my live set for about a year and a half now.

My machine is quite sufficient. I have done much debugging trying to find the source of the latency. From waht I can see, there is little to no delay (~ 5 ms) from when I receive a value in from live.observer, to when it travels through the logic to trigger samples.

I have tried quantization, and when I set it to 16n, it always comes in a beat late. Perhaps my quantization scheme is flawed. I will have a look at your patch nonagon and see if I can pick up any good tidbits.

But my fear is that Launchpad + Live.observer are intrinsically latent.

My machine is quite sufficient. I have done much debugging trying to find the source of the latency.  From waht I can see, there is little to no delay (~ 5 ms) from when I receive a value in from live.observer, to when it travels through the logic to trigger samples.  

I have tried quantization, and when I set it to 16n, it always comes in a beat late. Perhaps my quantization scheme is flawed. I will have a look at your patch nonagon and see if I can pick up any good tidbits.  

But my fear is that Launchpad + Live.observer are intrinsically latent.


One important thing I neglected to mention: assuming your patch is moving the playing position of a Live audio clip, you need set the clip to "RAM" mode to get good results.

I am recording into a buffer in my patch, and then changing the play position of that clip, no Live clips are involved.

M4L live.observer latency?