losing sync between loops during session

[genesis66]

Hi, I have setup luppp with non-mixer+jack+lmms-vst with external controler apc mini. Everything is working almost fine.....except that I "randomly" loose sync between loops when recording live pattern (singing or playing synth). When I launch luppp with the metronome, I set the tempo to the desired value, then load a few existing samples (drums, fx etc), then starts recording playnig rhodes or piano and singing, after one or 2 minutes, the lopps are totally "un-synced" with the tempo, and so un-synced at all one with the other. It's a real shame because this is just unusable right now. my luppp.prfs is set to 2 (sync best), and even then it's the same problem. Thanks for your help

[genesis66]

I have just notices (launching luppp via command line) that I have : Cannot use real-time scheduling JackClient::AcquireSelfRealtimeError might help

[harryhaaren]

Hi @genesis66,

There's a few different things going on: i'l like to know your exact version of Luppp, and if you're changing the BPM during the session?

The "resampleQuality" SINC_BEST has nothing to do with time-stretching or loop-sync, it controls the quality of resampling a session if you're now running JACK at a different samplerate than when the session started.

The real-time scheduling error might (probably will...) cause glitches / xruns, but is also nothing related to timing.

The 1.1 release from last-week should have fixed some sync issues: https://github.com/harryhaaren/openAV-Luppp/releases/tag/release-1.0.1 If you're still experiencing the issue, please inform, because perhaps there's an issue with the new timing mechanism. Its certainly much better than before, but perhaps still not perfect.. -Harry

[genesis66]

ok, the real time scheduling error is now solved (by changing priority to 70 inside jack settnigs) I am using luppp version provided with kxstudio packages (gives me "Main:61: Git" when starting luppp)

Basically what I am doing is turning the tempo knob to search the good tempo (using qjackctl to control digital value of the tempo), then I load a drum pattern sample (wav file), then I record a loop (playing keyboard)....that's it.

Should I first set the tempo before loading any sample or recording anything, and don't change it anymore ?

I am going to do some tests using the tap function and will let you know about my investigations

[harryhaaren]

What do you use QJackCtl for? Checking what BPM it actually is? Like 140 or 154? I can show that in Luppp if you like?

You have the older version of Luppp, build from git and this issue should be fixed :) -Harry

[genesis66]

Great, I installed it via "apt-get", I will install it from git tomorrow. Yes, I use qjackctl to check the BPM, well of course if it shows in luppp, I won't need qjackctl for that anymore.

[genesis66]

I installed the last git version, and the problem is still occuring. Just one loop, 8 bars and on second pass it is already out of tempo ! don't know what to do ,any suggestions ?

[genesis66]

after doing some tests, it seems to me that the loop lenght is the problem. Does luppp quantize the luppp lenght so that it fit to bars/bpm ? when you hit an empty loop (track N and scene intersection), it turns red (recording) on the first time of the pattern (4 bars mesure), if I just end the record by clicking again on the loop button it stops recording and should be adjusting the loop lenght so that next time it will start again on first time, right ? Did another test, just open a luppp session (empty), imported a wav file (drum pattern on 4 bars), the wav file is bpm 104, and current bpm in luppp show 120. If I play this drum pattern while listening to luppp metro I can clearly ear that it is not the same tempo. If I select "use as tempo" the luppp tempo decrease to 103 (detection problem) and the loop loose tempo sync with luppp metro after a few seconds. If I adjust manualy the luppp tempo to 104 ,same results after a few seconds...

[harryhaaren]

Genesis66 wrote: after doing some tests, it seems to me that the loop lenght is the problem. Does luppp quantize the luppp lenght so that it fit to bars/bpm?

Yes: this was a design goal of Luppp, to have record / stop-record functionality quantized to the beat. I'm now aware that most live-looping performers don't like this feature, and would prefer to have an "immidiate-on-MIDI-press" start / stop record feature. This is in progress.

Re Drum loop: please upload ( archive.org ) and link the file here. I can test it. Note that Luppp should slow to ~104 bpm. 103 is not a BPM detection problem: it means the .wav doesn't have enough frames to technically be called 104 BPM.

Cheers, -Harry

[genesis66]

here's the link http://we.tl/cWsM4DtFxg I perfectly understand the need to have the loop lenght adjust to "bars", sooperlooper doesn't allow that and works with free loops lenght, I definitely prefer your approach. But I also need everything to be synced together :)

[mrmowgli]

I'm using the latest version in KXStudio (They should package a newer version, if there's one stable enough) and definitely run into the sync issue. I also get this:

$ luppp
[Luppp] main:61: Git: 
[Luppp] Gui:339: Gui()
[Luppp] Gui:444: Loaded preferences
[Luppp] Gui:470: No session management in use
[Luppp] Jack:90: Samplerate 48000
event
event
event
event
[ DSP ] :0: Timing Error: negative samples 128
[ DSP ] :0: Timing Error: negative samples 128

I get a lot of these negative sample messages, eventually with snaps and pops, and then worse sync issues. Definitely would love to be able to stop and restart the loops without having to close Luppp. Or at least force a restart (With spacebar maybe?)

[harryhaaren]

Hi @mrmowgli, thanks for your comment. Using a "Scene Launch" command (can be MIDI bound, or '9','o','l','.' IIRC), will bring all loops back into sync.

I'm aware that the issue is a big one - unfortunately the fix is not obvious. I hope to release a new version of ArtyFX soon, and then finish this bug, along with some other cleanups. Cheers, -Harry

[geraldmwangi]

Hi Harry, I've testing Luppp I came upon the same issue when live-sampling my bass guitar. Jack is set samplerate 44100Hz, realtime. What I did: a) loaded luppp with the default tempo of 120bpm b) triggered track 1 on scene 1 for record c) Recorded 2 Bars (1Bar=4 beats on the metronom) d) let the clip loop e) after 8 bars the clip is audibally 180° out of phase f) I have a good feel for tempo, so listening to the metronom alone I think the metronom is stable g) Thus the clip length must be shorter or the clip is played faster at the same pitch h) got the git code and looked at looper.cxx, I found the variable playSpeed in process() i) printf playSpeed reveals playSpeed=1.018 and NOT =1.0 (I did not change the bpm! Still at 120bpm) j) commenting out playSpeed=(float)actualFrames/targetFrames, thus leaving playSpeed=1.0 (the default) and compiling -> luppp stays perfectly in sync, not matter how many clips are played k) this fixes however the clips to the bpm at which they where recorded, so bpm knob changes metronom but not the clip-speed. l) didn't do the numbers but actualFrames { as computed from samplerate (round number), bpm (round) and nr of bar (even number )} and targetFrames must also be round numbers m) printf'ing actualFrames and targetFrames, actualFrames is round while targetFrames is NOT round (thus they aren't equal)-> there is something wrong in the computation of targetFrames n) for now I'm leaving playSpeed=1.0 since I don't depend on changing the bpm while looping

Hope this helps, Gerald / JimsonDrift

[y1ds]

I was having the same issue. Changing the line playSpeed=(float)actualFrames/targetFrames to playSpeed=(float)actualFrames/(float)targetFrames seems to be keeping sync at least a lot better.

[harryhaaren]

Hi @y1ds,

Gerald / JimsonDrift has been doing awesome work and sending pull-requests[see below] - I think this issue is now resolved - @geraldmwangi am I right in says so?

Cheers, -Harry

[1] https://github.com/openAVproductions/openAV-Luppp/pull/111 [2] https://github.com/openAVproductions/openAV-Luppp/pull/110 [3] https://github.com/openAVproductions/openAV-Luppp/pull/109

[geraldmwangi]

Yes the issue is resolved. Loops stay in sync now since playSpeed has correct value now.