Clyphx pro sample accurate

[Razzkazz]

Is Clyphx Pro sample accurate?

I am having an issue whereby when I play from a clip with the code "[] sig 4/4 ; bpm 58" to the next clip with the code"[] bpm 191 ; sig 4/4 there is a slight lag on audio stabs at the beginning of the clip, when the 2nd clip starts, like it's taking a few milliseconds to get up to 191. I am using Follow actions to go from one clip to the next.

I also tried using a "WAIT" message in the previous clip, trying get add the change just before the clip plays and the timing is unpredictable, as in not always the same.

Can anyone help here?

[S4racen]

Yes,the action lists of X-Clips, X-Cues and X-Scenes are all subject to a delay of up to 20 ms. It used to be 100 ms!

There is a Q&A video explaining how this works on the website.

Best regards
Darren

[Razzkazz]

Hi Darren

thanks for the info, good to know. But is it always exactly 20ms, I guess not. When using the "WAIT" code I got varying results with the same value. I haven't noticed anything in the past, it's just there's a couple of quick stabs at the very beginning of where the change happens, so you can hear the catch up happening. I found a workaround, so not a major hassle

I had similar issue with M4L devices in the past sending messages at varying times, at the level of milliseconds.

Thanks

[S4racen]

Hi, no the delay is up to 20 milliseconds, it can be much quicker than that.

Cheers
D

[bxn]

Hello I'm having a question about this 20 ms delay you are talking about.
Does anyone know where the figure come from (is there a video) ? As I understand it would be the delay between pressing an x-control e.g and beginning action execution and not the base ableton tick delay (which is 100ms as when calling ControlSurface.schedule_message from my understanding).
I'm working on a control surface script and would be interested in being able to timeout function calls in a speedier manner than relying on this 100ms tick.
So if stray found out something .. ^^

Bests,

[S4racen]

Don't think he's about to give away that secret I'm afraid...

Cheers
D

[bxn]

haha I see ^^

[bxn]

I found it ^^
It's the Live API python class Live.Base.Timer that allows reaching this number whereas the ControlSurface.schedule_message corresponds to the 100 ms delay.
Numbers are not exact but roughly :
- The ControlSurface.schedule_message seem quite stable at a 99-101 ms interval but can vary up to 80 to 120ms (on my system).
- The Live.Base.Timer clocks usually at 14 to 19ms averaging at 17ms on my system.

[jbone1313]

@bxn Thanks for coming back and letting us know.

It seems schedule_message takes a parameter, delay_in_ticks. Do you happen to know what period of time each tick represents? Are you saying each tick is 100ms?

Edit: After some light googling, it seems clock ticks, in computing, generally correspond to CPU cycles, which are very fast, much more than even 1ms. I am not positive that is correct, and I do not know if Ableton's API clock ticks are the same. If I had to wager, then I would bet they are the same.

[bxn]

omg didn't see your answer I thought I had notifications enabled ..

tick is just a general programming word it doesn't mean it's connected to cpu cycles and indeed it's not !
Regarding schedule_message you're right the delay_in_ticks parameter corresponds to the tick interval until your function is going to be executed.
I don't have access to the api internals but it seems to be a stable 100 ms for the duration of the tick ! I don't know how they implemented this but it does not really matter and certainly they decided it should be 100 ms and that's all ^^. must be written in C++ somewhere I guess