Very High GPU usage on windows

I’ve taken a brief look through the code this morning and it’s obvious that Ardour is having to jump through hoops to make this work across all 3 platforms. In fact the underlying VST code seems to have been written at different times and (at least initially) by different devs and in different languages for the different platforms - ‘C’ for Windows and C++ for Linux and Mac. So there’s a very good chance here that quick fixes might improve VST handling for one platform but at the expense of the others :frowning:

We could do with getting a small team of testers together and a small collection of plugins that’ll work on all 3 platforms. If Robin’s willing to implement the fixes and Mike’s willing to test on Linux, I’d be happy to test on Windows and then someone else for MacOS. @BenLoftis if he’s available? Or maybe Dingo (over on the Mixbus forum)

1 Like

I see this issue started a big debate. If there is a fix for windows I would be happy to test it out with my session to give you feedback. However I am not able to build or compile anything :slight_smile: I can help if someone provides me a simple .exe where I just have to double-click.

Yes I just had a look at the Linux VST code too. Its not pretty, because of the need to hook X11 into GTK(2) at some level, but it works for what it is. Robin is right that the effEditClose and effEditOpen calls are in there - and, they should wrap the plugin UI creation / destruction in what I assume to be the correct way - the 4 steps I described.
But - it seems that the call / signal to the X11 VST2 UI engine to create / destroy the editor doesn’t happen - hence the plujgin / editor never gets that call.
It may be as ‘simple’ as adding some overrides to the hide / show functions in the Linux VST PluginUI class - though the structure would less ambiguous if there were explicit ‘open’ and ‘close’ mechanisms to differentiate from show / hide. But anyway - that’s as far as I’m prepared to go with it as I have paid work to do.

I will provide a debug version of a Linux VST plug-in that should output enough messages to tell if any changes are working as intended. (Robin I can send you a download / link if you email me). But I don’t have a means to build Ardour at present or the time to submit code.

@mike3 As a user I do appreciate the time you take to look into this. I find it very valuable getting insight from someone who has to support commercial plugins on multiple platforms, which will hopefully help to make Ardour more robust.

I know the forum is completely the wrong place to debug ardour code - but I don’t have a lot of other ways to contribute at the moment. One suggestion regarding our VST2 debacle - perhaps try a call to


in the LXVST UI destructor

LXVSTPluginUI::~LXVSTPluginUI ()

or something along those lines might be a clue. I can’t build Ardour at the moment, but just from looking at the code it appears the UI (UIWindow) base class gets destructed with the pref set to DestroyVST - since I get the message “PluginWindow deleted for… blah” but that call doesn’t ultimately appear to do anything to destroy the plugin gui itself for VST2 - on Linux. It needs to tell the vstfx ‘engine’ to schedule the X11 UI window for destruction on its VST2 gui X11 event thread. Then the plugin would get the effEditClose call etc

Another Ardour VST3 feature I’d forgotten about - it turns out if you resize a VST3 plugin UI, you can never make it smaller than the new size. Ever.
Result is that I now have a plug-in GUI which is bigger than my actual head - and the only way I can shrink it (the GUI, not my head) :slight_smile: is to delete the plug-in. I think I filed this as a bug a long while back but nothing happened.

Yeah it a known issue with some VST3, due to to a conceptual issue between gtk2 size-requets/allocate and VST3’s API for size-constraints. The vast majority of VST3s are however fine. anyway we’re really getting off topic now.

So are the vast majority of DAWs :slight_smile:

Just for completeness - And I don’t think its too off topic since we were discussing an issue related to VST3 UI behaviour -

For (future) reference: The “conceptual issue” is that Ardour assumes that the UI dimensions provided by the plugin when its UI is first instantiated (via call to getSize etc) are the smallest dimensions the UI can be. This is (trivially) incorrect.

Supposing I created a graphical EQ plug-in, and I want to present it to the user at a - reasonable - size, or, the size it was when it was last opened (and I can’t guarantee that all hosts will remember that last UI size correctly, so I have to handle that myself just in case).

But, I also want the user to be able to shrink the UI to the size of a postage stamp, if they choose (they might just want to temporarily shrink it out of the way, but still have an overview of its configuration for example). This is perfectly legal to do. And indeed the checkSizeConstraint API provides the mechanism to do just that.

If the user resizes the window, you can use checkSizeConstraint on the plug-in to present the requested new size to the plugin, and the plugin will return the closest size it can manage.

In the case of trying to shrink the UI down below its minimum dimensions, that would just be the minimum dimensions (not the UI’s default dimensions).

You can then handle / provide onSize requests as necessary and the plug-in should be able to respond appropriately by resizing its UI (assuming it has returned kResultTrue for canResize() ).

I find it odd that this is characterised as some kind of ‘gkt2 issue’ because you can already grow / shrink ardour’s VST2 window beyond the size initially presented to the user (though obviously the specifics of resizing a VST2 plugin GUI are quite different to VST3)

A user can shrink UIs below its initial size just fine (assuming it fits below ardour’s plugin toolbar) e.g. u-he plugins. Plugin UI can also shrink themselves (expand panes). The issue I refer to relates to aspect ratio (checkSizeConstraint) causing runaway resizes (initiating a resize could cause endless shrinking or growing, so this is currently commented out).

Anyway there are a lot of issues with VST support in Ardour, but at least the high GPU usage caused by some plugins can be worked around.

Short of waiting a few days for for Ardour7, you can get a nightly build: Ardour - Nightly Builds

While that is an .exe to double-click, the preference to destroy plugin UIs when closing the window is not available in the GUI (due to A7 release preparations).


  1. Install Ardour 7
  2. Launch it once (Ardour writes default preferences to disk)
  3. Quit Ardour
  4. In Explorer type %localappdata% (this will open a hidden folder C:\Users\YourUsername…)
  5. Navigate to %localappdat%\ardour7\ui_config, edit ui_config in a text-editor
  6. Find and change the line
    <Option name="plugin-gui-behavior" value="PluginGUIHide"/>
    <Option name="plugin-gui-behavior" value="PluginGUIDestroyAny"/>

Can you tell me which Uhe plug-ins? (for Linux) the one’s I’ve tried e.g. Diva are not resizable at all as far as I can tell.
[EDIT] Unless you mean setting the default size via the preferences which is not the same as ‘Live’ resizing by dragging the Window, which is the case I was referring to.

I suspect the issue with not being able to live resize a VST3 plugin window smaller than its size on first creation, could be related to the window / widget’s ‘size_request’ (confusingly, this is GTK for ‘minimum size’) e.g.

When I call resizeView from the plugin, Ardour momentarily resizes correctly, but the resize event it triggers internally, simulating a user resize on its window, then seems to cause it to snap back to the old size. Maybe you need to update the ‘size_request’ on the host window accordingly when you get resizeView from the plugin?

Also Mike you are suffering from the like disease.

If I would ask if you could implement a service panel into your Pultec style eq plugins where one would be able:

  • to set input and output gains
  • to set input and output in linked way to find desired saturation level
  • check levels on a vu/rms meter and/or THD meter
  • be able to adjust the 0dBu reference level
  • be able to bypass the HP filtering
  • be able to bypass the tube-transformer saturation (for totally clean operation)
  • be able to bypass the LF section and the HF section selectively
  • be able to switch between the Overtone saturation model and the ACMT one
  • be able to use all the three Plutec eq in one plugin

Or adding some meaningful names to your plugins instead of the letters and numbers.

Now probably you would dismiss all this requests, you will have your own explanation and justification, even if I would say that other implementations does all this. And you would do nothing in things like this for your users.

And there are many versions of the plugins on your site, really confusing, and what is the real difference? The skin. Why don’t just implement a skin choosing feature?

Here we are, Mike.

Puts on Mod hat:
Ok I am going to steer things back on track to discussing the technical issues, lets avoid any personal attacks or insinuations in either direction.



I hope I’m not being dismissive, but these represent just a few of many, often contradictory, suggestions I regularly get from many fine and wonderful people who email me with interesting suggestions for what they feel would make the ideal plug-in. I’ve taken the time to ensure the technical questions you submitted by email have been answered, and I hope it helps you to get the best from the plug-in.

With all the best intentions, if I were to implement all the suggestions I get, I wouldn’t have the time to create anything new and the resulting plug-in would likely be completely bizarre. Different users have different requirements, and what you see in the final product(s) is the attempt to distil this down into something which is easy and intuitive to use, accurate to the chosen design, and flexible enough for most needs.
The difference is that these are ‘wouldn’t it be nice if…’ suggestions, whereas the specific issue I was referring to was a bug. A feature (closing the plugin editor) which the developers had chosen to implement, and which didn’t work as expected. The ardour developers can choose to ignore any such requests if they want - of course, Ardour is their project - but I’m happy to report that this appears now to have been fixed in Ardour7 (and it only took a few years to get there… :slight_smile: )

Hello, I don’t feel good reviving a thread that got somehow so emotional, but I finally found the time to test out Ardour 7.1, and seems that the GPU usage is still very high in my Session and the DAW is completely lagging when opening multiple of those Neutron plugins :confused:

I recorded a video showing what happens, basically in the beginning everything is smooth, then I open a lot of Neutron plugin windows, and it starts to get very laggy (freezes > 5 seconds). However interestingly the plugins themselves do not lag (as shown in the video) but only Ardour itself.
The high GPU usage (45%) is not so surprising to me as these plugins have a fancy UI and stuff, and I can deal with closing windows that I forgot to close.
However, the problem is: when closing the windows it’s still freezing very much and barely usable when I start the playback again. (need to close Ardour and relaunch)


Then I tried more or less the same in Reaper, I create 15 tracks, add 15 Neutron plugins and open their windows. The interface gets laggy as well and the GPU usage goes up a lot ~45% (similar to Ardour), but then when I clos the plugin windows everything gets smoother the more I close them, at the end the UI of Reaper is completely running smoothly again. And the GPU usage is back to normal.


So I’m not sure what the problem could be here, maybe someone else has an idea… (the plugins are VST3 :slight_smile: )

Have you enabled Ardour > Preferences > Plugins > GUI > Closing a Plugin GUI Window … destroys the GUI instance ?

Oh I must have missed that in the thread, I thought it is now default behaviour. Sorry :confused:
It works now thanks a lot!

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.