Timesignature for Marker on Timeline resets to unwanted value

[polyrod]

Hi,

if i have multiple time markers/regions with signature change , say marker 1 bar 1 time signature 4/4 marker 2 bar 5 time signature 7/4

it first works ok , then after autosave or opening a midi clip in pianoroll , timesignature for marker 2 gets reset to 4/4

[rncbc]

can you elaborate on the steps and evidences to this is happening please? how are you setting the time-signatures? do you know that MIDI clip editors may have an alternate or "secondary" time-signature, which might be different from the main timeline? is the main timeline (tracks) time-signature being reset when you open a MIDI clip editor (aka pianoroll) or is it that you set an alternate time-signature specific to that MIDI clip in particular ? you should look both to the main time ruler and the piano-roll time ruler as well... watch whats being reset as you say.

[polyrod]

Hi again,

here is an animated gif of a session where time signature change happens on main timeline. https://gifyu.com/image/Szrwj

i only have cliptimeline in pianoroll visible when clip "touches" main timeline marker with signature change. midi clips where all created in qtractor/ no imports

in the gif you can see i am looping several times and nothing happens, then suddenly wush signature change.

i am only setting time signatures in main timeline.

Hope it is obvious now , in case not , ask for more clarification.

Thanks

[rncbc]

thanks for the animated evidence; there I can see that the it is the time-signature on bar 1 (and not bar2) changes on the 2nd loop turn-around ;

but still I have no idea why that is happening :(

may you move/shift all your session one bar or two to later (to the right) so that the loop-start point won't fall at absolute zero location (ie. bar 1) and then check whether it all happens as same?

[polyrod]

Hi again,

ok this time i made 3 sections:

1. bar 1 at 8/8
2. bar 8 at 4/4
3. bar 14 at 7/4

i moved all clips over and set the loop initially to not go past start starting from bar 8 and it seemed nothing unexpected happens.

then i moved loop point back to bar 1 and after some loops bar 8 switched to 8/8 .

i reset timesignature while loop was running , but i had to stop playback cause audio stuttered. i started again , and at bar 8 it switched again.

i reseted the time signature again bar 8 to 4/4 and moved loop start point again to bar 8 , expecting nothing unexpected to happen, but after some loops again , i let it play from start (bar1) into the loop (bar 8..end) this time signature at bar 14 changed from 7/4 to 4/4.

hope that helps.

here is the gif, this time even longer :( https://gifyu.com/image/Sz54B

if i think about it , it seems like: https://pastebin.com/4Sm2HhPv

[rncbc]

is there any other jack_transport/timebase-aware application running in the background?

please try set Transport > Mode to "None" (or anything else but "Slave" or "Full") and test it all again... sorry that it takes a while before the "spontaneous" time-sig change occurs: looks it's sporadic which might be a sign of a race condition due to other running timebase (BBT) masters running wild behind the scenes...

ps. jftr. what's your jack settings re. sample-rate and buffer-size ?

[polyrod]

hi, i am using pipewire already , so buffsize and sample rate may change dynamically i will try with transport mode none , and check if it still occures .

[polyrod]

ok , i couldn't test with the known project , because when i switch transport mode to anything else but "full" , qtractor crashes. did a test project without session management only qtractor and there bug happens only in "full" mode , all other transport modes seem to be fine.

heres the gif : https://gifyu.com/image/Sz1Te

[rncbc]

hi, i am using pipewire already

wow. ok. can you redo the tests again with good old jackd(bus) ?

I suspect this is then all a pipewire issue instead... having no so equivalent jack-transport and timebase(BBT) implementations and behavior and that its switching of buffer-sizes all of a sudden and anytime which was a "bug" supposedly mitigated recently (>= 0.3.46)...

ok , i couldn't test with the known project , because when i switch transport mode to anything else but "full" , qtractor crashes. did a test project without session management only qtractor and there bug happens only in "full" mode , all other transport modes seem to be fine.

which qtractor version are you running anyway? if not already, can you test with latest git master (>= 0.9.25.12git.ab4baa)?

thanks && cheers

[polyrod]

Ok version is Qtractor: 0.9.25 pipwire is at pipewire:amd64 0.3.43-2 amd64 i updated pipewire to 0.3.47-1 now. trying again , an after i check with jack

[polyrod]

Ok , with new pipewire it still does tsig change in "full" transport mode, however now i could switch to other modes without crashing qtractor and in "master" mode it runs without changing tsig.

As for trying with jack , i tried to revert to jack , however i didnt succed because of dbus can of worms and i cant remove pipewire completly because debian relies on it, so i wont revert to jack.

I am building latest qtractor now. ok also with pipewire 0.3.47-1 and qtractor 0.9.25.12git.ab4baa tsig change in "full" transport mode. Guess i stick to "master" transport mode for now.

[rncbc]

i mean, it all means that PW timebase callback is being issued to clients after a relocation (eg. loop-start turnaround) but with old or former jack_position and BBT data (as was before the relocate or turnaround)... being that true, it's a dang PW issue for sure

[polyrod]

So what now ? Report "what" to Pipewire Dev Team ? What do you think , how to proceed ?

[rncbc]

don't be so anxious :) we're still on the suspicion stage ;) and PW is still a toddler anyway... first you'd confirm that there are no out-of-nowhere time-signature changes when using the real mccoy jackd(bus), then probably file a PW issue on jack-transport/timebase synchronization whatever :S

[polyrod]

ok got qtractor running with jack and even in "full" transport mode , doesn't seem to change timesig. Guess you are right and its a PW issue all from the start.

[rncbc]

so it's true, PW is to blame here :(

and now you know you should at least keep Transport > Mode to "None" (or "Master") if running under PW premises... cheers && and thanks a lot for the patience in dwelling on this avenue ;) byee