Hi, I notice that jumping between parts with Flexiloop, VL sometimes looses the sync with the tempo and starts playing a bit off beat. When jumping then a part back or forth, the tempo is in sync again. Just listen to the video, it happens around 0:08. This happens not all the time, but I can reproduce this bug easily. I would not want this to happen during a live show 
to be clear; the metronome stay in beat, the audio limps behind around 0:08. Back in sync with the next partjump at 0:18
Yup this happens to me also. Not every time and not predictable. I was trying to find what might be triggering it, but you already reported it so my two cents here.
And happened to me during live 
All flex looping songs are off after that until it is fixed. But I canāt do a reproducible step by step procedure.
Can confirm, I believe it happens if you jump/exit loop very fast at the end of the loop, no time left to preload the audio of the next part so it goes offsync ā¦ usually for me does not happen if I have flex loop set to loop end and I push next part very early during current part, so it have time to load following part audio/video.
Cheers, Ciro
Hello @ciro1983811 ,
Yes I suspected the same and there was another topic mentioning this, but it doesnāt matter when I trigger the part change. Let me explain:
I use flexloops only for infinitely looping single part of a song. Which is an audience interaction break. And once it is over we are moving to the next part. These are not very short parts and I have total control on when to trigger next part (meaning not time critical, and Iām not using it as a pattern sequencer.)
Basically Iām just looping one part on a linear song for unknown number of times and then continuing with the rest of the song. Triggering early or late sometimes it does and sometimes it doesnāt.
I havenāt touched this for a long time but will try again, but from my memory if you have multiple tracks, some are still in sync and some arenāt so the band cannot catch up. Only solution is to stop transport mid song. Funky stuff.
Only difference from what you are telling is Iām using āpart endā instead of āloop endā
@musicullum as this issue is confimed by others, can you take a look at it?
Will check. Of course the system needs some time, so there may be dropouts if you donāt give it any, but it should not run out of sync - at least, it should then recover after about a second or so.
Yeah this is not like part change dropouts with high cpu usage where there is a pop/crack then recovery.
This basically some tracks completely going out of sync and then staying like that unless you stop transport and start again.
Thatās correct. Also when out of sync, switching to any other part, that part is back in back in sync again.
Can confirm that switching to another part also get things back in sync.
Clip Laucher needed
@musicullum any updates on this subject?
Btw, the sync does not recover after a second or more. You have to change part to be in sync again
Looks like we found the culprit for this case with FlexLoop jumps running out of sync. Not easy to catch because it is hard to reproduce, happens only rarely. Give it a try with the next version, thanks for reporting!
Tnx Musicullum, will keep an eye on it
Hi, have tested with 2.2.105. Been playing with Flexiloop, the jump out of sync seems to be solved. However there is a small hickup. When switching between parts, VL sometimes plays a fraction of a another part(in this case part 1 the metronome)before playing the chosen part (part4 is this case). You can hear this in the clip around 0:04
@musicullum any updates on this one?
Looking at it right now. Could you send a .vlprj file? No audio files needed, just the project file. Setting up exactly what you did by watching the video over and over is pretty time consumingā¦
Cannot reproduce. Could you try and set Part 4 to 7.1.1 instead of 6.4.4, does it make a difference? Just wild guessing.
flexloopbug.vlprj (577.2 KB)
I set Part4 to 7.1.1 and makes no difference, can reproduce
tried again, no problems here. Thatās with the next version, so give it a try. If it persists, we need more details.