Sure, the settings are changed immediately, but the change is not
written to disk. So say I change the Frames/Period setting to 512 from
1024. That works for the current running instance of jackd. But the next
time I launch the daemon after stopping it? Back to 1024. And worse
still, the settings dialogue still shows 512, so it's incredibly
frustrating and confusing to the user when they're trying to match
settings across two computers for something like jacktrip and it looks
like they match in the UI, but they don't in reality. (And on next load,
because it wasn't saved to disk, the 1024 reappears and the user is left
scratching their head as to why their settings aren't preserved.) Also,
pressing cancel and not having the UI reflect the previous changes
instead of the original settings? Definitely not a feature.
Additionally, the fix I've provided doesn't prevent the Frames/Period
change from happening immediately - that part of the code is unaltered.
If the jack daemon can change its settings immediately, it still does
without reset. Feature preserved. What it does do is to actually write
the change to disk for future instances of the jack daemon, so that the
user doesn't wonder why their old settings keep popping back up.
Aaron
On 27/3/20 06:57, Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
which was filed against the qjackctl package:
#954658: qjackctl: Frames/Period setting not always saved when it's the only
setting changed.
It has been closed by Dennis Braun <d_br...@kabelmail.de>.
Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Dennis Braun
<d_br...@kabelmail.de> by
replying to this email.