(as an aside, if anyone can point me to how to use waf to build debug mode and run via debug mode in qtcreator so I can set breakpoints, that would be nice. I guess I must have lied when I earlier said I could run debug mode in qtcreator…seems I can build and run, but not debug)
The default build is debuggable (unless you explicitly use ./waf configure --optimize ...), and the easiest is to run it in gdb directly from the source-tree: ./gtk2_ardour/ardbg
I don’t know nor use qtcreator, so I cannot help you with that end.
PS. For debugging I also recommend to use Audio-System: Dummy. That can halt and allows single-stepping without any interference of realtime audio threads.
Am noticing VST3X11Runloop:registerEventHandler() gets called twice when adding a VST3 plugin, with this same call stack:
Happens either with SonoBus VST3 plugin or CHOW VST3 plugin. I’m still familiarizing myself with the code, but this looks fishy.
Curiously, the first time in registerEventHandler the variables initially look like:
The second time the variables initially look like:
And then upon deleting the SonoBus plugin, then unregisterEventHandler() only gets called once, with this initial state of the variables:
This is JUCE’ doing. A plugin registers itself twice yet unregisters only once:
ok, well that commit (prevent registering multiple identical file descriptors · Ardour/ardour@c075d3a · GitHub) is included in the current master code I’m working with. And that if statment is skipped over both times, so the subsequent registering happens twice still.
I guess the “fd” file descriptor variable is different on each call (48 first time, 52 second time).
What I’m looking at now that seems suspicious is that the following two functions keep alternatively hitting the breakpoint I set at the start of their function:
VST3X11PluginUI::view_size_request()
VST3X11PluginUI::view_size_allocate()
This type of “view size” function seems like something that should only happen like once at start and then whenever use modifies the view size. Not continuously.
And the _req_width is always 1140 and _req_height is always 660. So the view size is not actually changing…
CHOW on the other hand only calls those resize functions just a few times initially, but after startup complete will run fine forever.
So somehow the SonoBus is producing a constant stream of way too many resize triggers.
1 Like
I’m noticing the CHOW plugin doesn’t allow me to resize it with the mouse by putting mouse near the corner. But the SonoBus plugin does allow me to resize it with the mouse.
So maybe I should try another JUCE plugin that has resize ability, and see if it is affected as well, so I can determine if this problem is SonoBus-specific or rather happens with any resizable JUCE VST3 plugin. I’m not familiar with VST3 plguins, so I will just try installing a few to find one.
Robin, should I try that PR and see if it works?
Preferably re-compile sonobus with VST3 in Ardour on Linux - resizing fix by ctsexton · Pull Request #867 · juce-framework/JUCE · GitHub
1 Like
ok will do…skimming that PR and sounds like the problem lies with JUCE.
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.
2 Likes
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?
1 Like
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.
2 Likes
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!
3 Likes
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.
1 Like