Usually opening a plugin UI the first time is the action that requires significant resources. Disk I/O to load the shared object, CPU to map symbols and allocate memory for textures or display resources, open sockets or connect to display server and register with event loops.
And while mike is correct that a VST standard does not offer an API that distinguishes between closing a window and destroying a window, most plugins do in fact stop rendering when the is hidden (or even when obscured by another window). Izotope is a notable exception.
That’s why I asked, because I’m not an app developer.
It would be good if the developer community could get some sort of consensus on this too.
At least the Meldaproduction plugins cause resource problems with Linux/Yabrigge. On the Windows side, the matter must be investigated. Their support isn’t all that interested in figuring things out, other than for their “supported DAW.” That’s why I try not to use them anymore. Fortunately, there are alternatives, such as ACMT, LSP, X42 … And many more:)
There is no difference to what happens whens when closing a session or removing a plugin, while a plugin window is open. The same mechanism (drop_window) is used all those cases.
Still, I have just tested and your Linux Plugins behave fine. They also do not cause any additional load, when keeping them around, well done!
Could it be added as a new Preferences option? That way the user could choose between faster reopening of UIs and freeing up memory/GPU for closed UIs.
It has been added as a preference on git but having read this discussion, I think the default, without needing user intervention, should be to act the same as every other DAW.
The above line won’t compile here with either MSVC or Clang (they both throw up an error in ‘include\sigc++\functors\slot.h’ at line 103)
Clang tells me:-
Cannot initialize return object of type ‘bool’ with an rvalue of type ‘sigc::bind_functor<-1, (lambda at …\gtk2_ardour\processor_box.cc:4821:100), WM::ProxyBase *>::result_type’ (aka ‘void’)
MSVC tells me:-
‘return’: cannot convert from ‘void’ to ‘T_return’
BTW - my line numbers are different from yours because I built Mixbus rather than Ardour. Hope that helps.
There could be a small button in the plugin window so that the user can decide which window to close completely and which not. Whether this button is displayed or not could be set somewhere in the settings.
Is this the standard behaviour in DAWs in general?
It somehow makes sense, but if this is the cause for worse performance from Ardour over other DAWs, it should be thought about twice. Maybe there could be a forced “performance mode” with a hint, that GUI while loading plugin windows is slower, but saves ressources when it’s closed.
Well done Robin! It looks like this got fixed in the latest code (including a fix for the compiler issue!!)
Unfortunately I haven’t been seeing the problem here but please can @Reaw and @mrskytown download the latest nightly and let us know if it’s now working for them?
What’s the preference called, and how do I enable it?
(I’ve been looking through the preferences and as far as I can tell, the thing I don’t know the name of, doesn’t appear to be there - though of course I could be wrong…)
We generally refuse to add workaround to the DAW for issues that should rather be fixed in plugins. A similar reason why Ardour does not process isolate (or sandbox) plugins. On the upside, this particular GUI quirk does at least not affect DSP load and is rather trivial.
There has been no change in behavior. Ardour 7 is currently in string-freeze (no new user-facing texts, until translators are done), and release-candidates are out.
You could manually edit the %localappdata%\Ardour7\ui_config file and change plugin-gui-behavior to PluginGUIDestroyVST.
Yes I tried that. While Ardour’s behaviour is incorrect at the moment, that option is much worse. I can’t begin to describe how badly wrong that is - and I would be surprised if it fixes the issue raised, but, for VST2 at least, I would recommend users stick with the default option of Ardour’s ‘normal’ behaviour (for some value of ‘normal’) as the least worst option. Reaper does the right thing. Maybe they can enlighten you.
Mike, can you describe what’s wrong? I tried the PluginGUIDestroyVST change here, admittedly with just 2 plugins so far (both VST3 and both from the same manufacturer) but I didn’t detect any problems here.
Mike, can you describe what’s wrong? I tried the PluginGUIDestroyVST change here, admittedly with just 2 plugins so far (both VST3 and both from the same manufacturer) but I didn’t detect any problems here.
For VST2 with the pref set to destroy, Ardour now appears to destroy the Parent window, and by implication therefore the plug-in’s window as a child of it. But, crucially it still doesn’t call effEditClose on the plugin.
Therefore the plugin now has no window at all (not just hidden) and it doesn’t know about it. Not only that, but (perhaps because) it wouldn’t normally need to call effEditOpen to reopen a previously hidden UI, Ardour also does not call effEditOpen on the plugin when the user reopens the UI.
By some luck, the window still seems to reappear (maybe Ardour isn’t really destroying it after all, but the messages on the terminal appear to indicate it intends to at least, or maybe the dangling window ref just gets fortuitously reallocated) but after combinations of opening and closing multiple UIs I was able to get Ardour to hang. This doesn’t happen when you have the pref set to Hide.
Doing the same thing in Reaper, I can see exactly the behaviour I would expect - so I know my plug-in code at least - is sane:
Opening the UI:
The host creates a parent window, and passes this window ref to the plugin during a call to effEditOpen.
The plugin creates its UI, in a new window, which then becomes a child of the host supplied parent window.
…
Closing the plugin UI
The user clicks the close button (that’s the (X) in case anyone is still in any doubt… ) The host calls effEdiitClose on the plugin, and the plugin tears down its UI and destroys its window, which is then no longer part of the window hierarchy and is no longer a child of the parent window.
The host can now (safely) destroy the parent window.
The mechanism is more refined for VST3, so that might be alright, but maybe some caution is required with VST2. I appreciate VST2 is effectively a deprecated format, but I can’t rework legacy plug-ins to mitigate against new bugs in Ardour, and some users still depend on them.
Could you get a backtrace? Which OS have you tested this on?
I assume Windows, since what you describe is what Ardour does for VST2s on that OS: Ardour calls effEditClose only just before re-opening the GUI, or when unloading the plugin. That code was added in 2011 and has no explanation in the [SVN] commit message. But it apparently worked fine for for years for users who switch to generic-edit and back.
For MacVST2 effEditClose is directly invoked after removing the plugin’s NSView from the superview from the main UI thread. Similar on Linux, where this happens from the VST-X11 event-loop thread, here just before the call to XDestroyWindow.
So that sounds like the right order of things to happen - e.g. I would expect the safe way to do this on Linux would be as described. Tell the plugin to close its UI via effEditClose, and then, once the plugin has destroyed its UI, and the window it created for it, you can close the host (parent) window safely.
If you do it the other way around e.g. destroy the host window while the plugin is still a ‘child’ of the parent window, and then call effEditClose, you might destroy the plugin’s window as a side-effect, and then the call to effEditClose will also try to destroy it, potentially causing Bad Window errors form X11 and I think we know what the default XLib behaviour is when that happens…
I assume Windows, since what you describe is what Ardour does for VST2s on that OS:
I was testing with Linux, and I didn’t see any calls to effEditClose when I closed the UI - in either configuration. The only difference between the two preference settings being that ‘destroy’ caused an additional message:
PluginWindow deleted for 0x55772aaead90
on closing the window - and the subsequent hang after opening / closing many different plugin UI windows in different orders. This did not happen using Ardour’s default (‘hide’ configuration).
The same plugin, in Reaper, gets the expected effEditOpen on opening the UI, and effEditClose on closing it, as with other host applications I’ve been able to test with.
If it provides any clues, I’ve also noticed that - on Linux - if I set the pref to ‘Hide’ then toggle between ‘Edit’ and ‘Edit with generic controls’ via the right-click context menu from a plug-in slot in the channel, the UI toggles between custom and generic as expected.
However, if I set the pref to ‘DestroyVST’ open the (custom) UI and then right-click to switch it to ‘Edit with generic controls’, the custom UI disappears, but the generic UI does not appear in its place. I have to do ‘Edit with generic controls’ a second time to get the generic UI to appear. That has to be an Ardour bug.
Switching back to the custom UI using the same method works (visually at least) as expected.
I also noticed while testing, that the default configuration appears to be not to scan for new plug-ins on startup. Nothing particularly odd there, but this leads to a uniquely ‘Ardour’ side-effect.
If I use a plug-in in a project, save the project, and then for some reason I install the same plug-in again (or perhaps a slightly modified one I just built - for example to debug some odd VST UI issue - see above) or even just an updated version of the plug-in, the next time I open the project, Ardour tells me the plug-in is ‘not present on the system’.
What this actually means (after I wasted an hour or more trying to figure out what I could have possibly broken in the plugin - but, since I already wasted my entire weekend, and today on this merry little game - what does that matter…) is that Ardour has detected that the plug-in is a newer version (more specifically a file that was installed more recently) - but - because it hasn’t been scanned, it characterises it as a plug-in that doesn’t exist - and hence the misleading message.
The effect to the user (remember, this is the default behaviour) is that they save a perfectly good working project. They install an updated version of a plugin, or even just do something which inadvertently ‘touches’ the plug-in .so file - and the next time they open the project they are greeted with warnings that the plug-in they just installed ‘Cannot be found’ and is greyed out. Immediately this appears as if the newly installed or updated plug-in is defective and the plug-in developer’s good name is unwittingly besmirched
Sure, but the entire point of my rant is that what I described is the default configuration. How would the user know they were supposed to do that? Perhaps they’ll stumble upon this thread - or maybe it’ll be defaulted to something more sensible in Ardour7
) The host calls effEdiitClose on the plugin, and the plugin tears down its UI and destroys its window, which is then no longer part of the window hierarchy and is no longer a child of the parent window.