Yes, then again as quick/dirty workaround you could also try applying the PR to ardour.
adding that extra else if in the JUCE did the trick. Recompiled SonoBus and GUI is very responsive.
ok, so I guess the question is what to do to get this resolved? I see in that JUCE PR VST3 in Ardour on Linux - resizing fix by ctsexton · Pull Request #867 · juce-framework/JUCE · GitHub it sounds like the host-specific workarounds are not the ideal way to fix it. So do we just need to lobby JUCE to produce a proper fix?
Thanks for helping track this issue down, and confirming the fix.
Right now it is still unclear what the best way forward is. GUIs using Steinberg’s SDK directly do not have this issue and it seems to be a JUCE issue.
It could also be possible to prevent these recursions in Ardour by checking if the size has actually changed. Ardour also doesn’t yet use VST3’s checkSizeConstraint
either.
Anyway, for now I think we should wait for some feedback on the JUCE PR and why JUCE calls peer->updateBounds
.
I generally don’t wait to fix things in JUCE, I have my own fork anyway with lots of other changes. So I can apply this PR for now to at least solve it for SonoBus purposes. However, it is a good question why it calls peer->updateBounds() at all… will experiment to see if it breaks things in other hosts and platforms simply not to call it.
Probably a good idea to prevent a recursion in Ardour too by checking if size changed, regardless. Thanks all!
The JUCE team has implemented a fix that appears to resolve the endless resizing issue. Working pretty well for me so I’ve closed my PR regarding the updateBounds call.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.