Rui Nuno Capela

> I think this can be fixed by setting the [Qt::AA_EnableHighDpiScaling](https://doc.qt.io/qt-5/highdpi.html#high-dpi-support-in-qt) when building with Qt5. maybe you wanna have a look around here: https://github.com/rncbc/qjackctl/blob/e3c15c65c7628e13795d3eaff78a0de279737bc0/src/qjackctl.cpp#L557 - it's been enabled for Qt5...

issue (probably) lies on an old Qt5 perhaps?

i do see your point and the UX potential for this, but this kind of "automagic" selection would have to go and resort to udev signaling and what not and...

you can at least run _`qjackctl --preset`_ _PRESETNAME_ ... and it will (try to) switch accordingly (if qjackctl is already up and running in single instance mode)

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...

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...

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......

> 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......

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...

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...