My bad I meant VST2.4, the last version of VST2 which came in 2006, I don't know much about plugins back then, but looking at 2009 Nexus 2, it seems they weren't resizable at all. Actually to prevent the reinitialising/flickering when resizing double buffering needs to be used. This is probably taken care of in newer libraries like Cairo (Youlean Loudness Meter 2).

 

OSX uses triple buffering since ages, dont worry about that. ;)

the issue with plug-in interfaces is just that it is has to take care about the window on its own, which seems to be quite difficutl to implement and maintain.

just as many developers had their difficulties doing drawing, refreshing and reinitialisation right in old times.

the GUI itself, as others mentioned above, is another story which comes on top. first of all you need a plug-in interface which supports to know how big the window is and have that spec followed by all host programs.

so in other words... actually i wonder why protools does not support it for a bit longer than others. for VST and AU it is no suprise.

for me personal a generic, mandatory "50%" and "200%" option for VSTs would have been enough, i dont understand why people want their plug-ins fullscreen?, my workflow rather requries that i see as many as possible.

 

btw, waves 12´s stepped scaling is a real fail, you can see here how difficult it is to make that working for fonts and bitmaps, but they had the right attitude when they made it a seperate distribution/installer so that you can choose if you want it or not.

 

I agree, that would be enough. Like the now famous NeuralDSP plugins. And it would be way easier to use native fonts because the scalable ones unless you have a 4K display can break your eyes.

 

Also, provide the host with info on each automatable button/knob/slider, also whether knob is linear or logarithmic. In VST3, GUI and DSP is separated, so internally devs can distribute the GUI work to GUI team and DSP code to DSP team. This makes DSP offloading possible as well (UAD interfaces do this). However this separation, while good for big companies with separate teams for UI and DSP, becomes difficult for small devs. Hence, some VST3 plugs are like VST2 only structure wise.

 

I have a problem and I thought that maybe you could provide a resolution.
I am interested to read the text in the box. It is too small and when I zoom in it gets too blurry.

 

Prime example of good idea implemented so badly...

 

I think the next version of VST should force MVC by not allowing any GUI specific data in the computational classes of a plugin, but it should also offer developers something convenient and easy to create their UIs or even allow for a LUA layer so that if people choose to they can create custom scalable UIs or overlays.Think of all the custom UI mods and addons that are possible in game engines that have a UI overlay and it's all accelerated and GPU dependent, with a pretty small footprint.

Apple is trying to push MVC as a standard in XCODE especially with SWIFT as it will facilitate their flexibility in changing whatever they want since a properly written application will compile to new instructions and API easily if written properly as long as the compiler takes into account the changes, since apple is providing the compiler a developer only has themselves to blame if breaking updates happen because they wrote shitty code.

It is the correct way to do thing, problem is people always resist change for the sake of 'resisting' even if it is change for the better. We all do it and some of us are more intransigent than others. There maybe semi-valid reasons, but the facility gained always justifies the effort put in the future, but if you are unsure about the future maybe you don't see the point. That's just life.

One of the biggest problems in modern computing efficiency is bloat and this hanging around and legacy code with legacy UIs, sometimes with extremely complicated workarounds are just an other example of it.

 

not sure what you mean, GUI is always seperated from DSP.

dont forget that GUI scaling means more than pictures. it also means mouse and keyboard, initialisation and closing.

VST3 requires the plug to include things like "make every parameter which is included as GUI element accessible for a contextmenu controlled by the host" and things like that.

and even without that VST shit free scaling brings always the problem that mouse input had to be scaled, too, which isnt doable ideally.

example: if you have a slider which is 200 pixels high, and the user sets that parameter using the slider, it will set a parameter value of 0.95 if the slider is at 190. when you now resize the plug-in window to 130% that slider will be 261 pixels high - and now the plug-in has two options: keep the value at "0.95" and set the slider as close as possible, or set the slider new, so that is at the closest pixel (or at the perfect float position) but then the parameter value will change to 0.95347 and you can never set it to 0.95 again using the mouse.

so even withouth the usual VST SDK hassle making a GUI scalable always forces you to use methods which will work in that situation without causing too much extra work. if you are lucky, you used GL in the past, haha.

 

I just hope whatever they make, that they don't do like Arturia, that to make 1 plugin has folders with 10k files just for GUI. It's nightmare.
Resizable ok, but make it vectorial, not with 8000000 files of different resultions to have 95% 90% 85% 80% 79% 78% 77.5% like cmon man. basically slows down any search on drive C of any type, any antivirus scan for those that care, and takes 99 h to install.

Anyways the only plugins with really good interface are fabfilter. Everything else looks so badly programmed when compared to them. It seems just obvious to me that all developers should start programming like fabfilter. Obviously change the look of the plugin, but whatever has been done in fabfilter to get this GUI to work like this and to have such fast loading times should be done for all others. Maybe in another 50 years when the first human will land on Mars, we will have better programmers.

 

thats the point, fabfilters plugins look like they are a real computer program. but plugins looking like an old hardware device are en vogue, and those require "photo realistic" graphics. no need for better programmers, its a design decision, possibly driven by market needs.
i like the fabfilter's too, they simply work, and look very nice!

 

I basically agree. The biggest problems are:
1. GUIs libraries/frameworks are hard to develop. That's the main reason even the official VST GUI is community based since a while now
2. Cross-platform GUIs are even harder
3. No big company do GUIs with C++ since many years now. Apple has Swift, MSoft .NET/C#, Android has her own thing with Java interpreter based (Java.Kotlin), and so on
As for VST related problems:
4. Low file size is very important

The only true cross-platform mature C++ GUI that I know are:
- Qt: the oldest one. It's very complex and went commercial some time ago. Too complex for VSTs, especially the size.
- WxWidgets: the only really free. Still a bit too complex for VSTs, especially the size

This is true in theory, but not in practice because it has big drawbacks. The moment the GUI has many controls and text the performance falls down.
It's called immediate mode GUI (you draw everything 60 times per second no matter what) vs the traditional retained mode (you draw and only modify when it changes). Also there's "mouse latency" when you move a knob/slider and stuff.
But they're very cool for some things.

 

Last edited: Feb 24, 2021

I can think of two frameworks that are relatively low cost or free for small developers that can step in right now, are comfortable with GPU offloading and multi-threading and can support a layer with very little resource usage on controller. They are both still young and flexible enough to be done the best we can do them now, before they bloat and solidify.

JUCE & NoesisGUI

The controller will always produce a calculated value as that is it's job, GUI operations don't necessarily need to be sample accurate. The only big issue is how efficient the hooks and api are between the controller and the view & how comic or complex the view renders can become. This depends on a the hooks a plugin makes available, there are just not that many values that are output that are not attenuated or averaged, the rest is PCM information which isn't necessarily desirable in all instances. If a MMO game engine can deliver 40/80 non predictable quasi random event streams each with multiple parameters over TCP/IP and render that information with a custom layer all in under 80ms from NIC to screen,than local processes sing with much smaller in memory values isn't the roadblock to progress.

I agree with you a 100% there just isn't a good standard lib that covers all the bases and that is something that should be worked on, and it will be much easier to work on that if MVC is enforced as part of the standard. The same arguments were in much broader applications and no progress was made until MVC became a limiting factor. I don't see it as a limiting factor for C or any of it's derivatives because it is still OOP. If there was a Functional VST library the optimizations of bundling might exceed the rewards of separation but we are not skiing down that mountain so I am going to avoid that slope.

There has to be an upper limit to everything, and even then I don't think that is the issue. FabFilter's modern plugin's which are probably the standard for UI innovation right now don't use any more CPU than some of the older more traditional looking plugins that emulate rusty cyberpunk gear from the future-past and they come in with much smaller payloads per plugin.

I know it's not trivial especially when we are all used to doing something in a certain way, but since I am talking about a hypothetical ideal. Sooner or later if you want to move forward you have to close some doors, some people will be unhappy but that is just the way life is. You can not please everyone. I still see people shedding tears about not longer being able to use their 32-bit binaries on contemporary machines running contemporary OSs, when nobody forced them to get rid of their old machines that were working just fine and supported those binaries quite well.

Anyway, I digress, it takes me a very long time to type even with the text to speech. I am now exhausted.

 

I didn't include JUCE because I was talking about it but of course it's one of them. I don't know about NoesisGUI, too much closed for me to even download a Trial version.
It seems you weren't talking about immediate mode GUIs. Pretty much all mature GUIs are GPU accelerated. Microsoft's with Direct2D, most cross-platform ones with OpenGL, Apple's with Metal (I think it's its name). Even Windows 2000/XP's Jurassic system (GDI) is GPU accelerated.

I think the VST3 dsp/gui separation is good enough, but not how they implement it. Both of them. It's based on dated ways of designing C++ code that basically over-complicates thing. @demberto knows more than me about this.

I'm sure every C++ developer would kill to have FabFilter's GUI code lol. But a scary possibility is they're so good because it's very hard to code with it.

Have a rest, you wrote some very interesting and clever thoughts. Food for my brain. You've more than earned it

 

Last edited: Feb 24, 2021

In VST2, separating both was a hassle. Check this for more info. The host has more control over the plugin in VST3, which allows for more efficient plugins. FabFilter does its own GUI from scratch, they have their own designers.

 

well, you only need to do that once then you have your own system for the second project. ;)

i remember well when steinberg started recommending to use GUI sliders as actual parameters - which of course stopped working as you left VSTGUI because you preferred to make an GL interface, haha. but it is not like you would have to follow that propaganda.

i mean, look what NI was doing at VST 2.x times - or flowstone, where you code assembly to draw shapes.

pluggo had its own layer independent from vstgui, it even allowed to you use GPU based shaders before anyone else had that option in VST.

the MacOS9 version of the soundhack plug-ins were using quicktime(!) for the interface.

it all worked - maybe it is 3 lines of code more compared to VST3 - but the basic idea doesnt differ much.

i guess it is not correct to blame vstgui for its limitations, because without it many people would not have been able to make GUIs at all.

 

Last edited: Mar 3, 2021

you suggest that at apple they are using swift themselves to make their apps? ;)

 

Ever since Cocoa & Cocoa touch apple has recommended strict MVC regardless of which language you choose. Just because XCODE now comes with swift doesn't mean that it has deprecated the included Clang C++ compiler & it's LLVM. Base BSD -> libc++ as far as C++ OOP base is concerned. XCODE's new Inetface builder now works with Metal as is optimized for scalable displays and one source multi-layout views.

I am not sure how that is related to VST GUI. Maybe for AU dev work, but AU has it's own issues even if GUI isn't one of them.

 

Maybe custom developed-from-scratch drawing is the only solution for a resizable, modern, efficient, GPU accelerated, high DPI cross platform GUI. Else forget the GUI and go Airwindows style instead of using tons of PNGs like Waves etc.

 

Mostly yep. Like Microsoft with C# .NET.
The speed-critical parts of every framework are still developed in C++ (Windows)/Objective-C (Mac). For 95% of the developers, especially if they want a GUI, Apple/Microsoft forces their hand to use Swift with X-Code (or whatever are called)/C# .NET with Visual Studio.

It's not like it can't be done. It's just if you want to be productive there's no competitive alternative. For instance Studio One has problems with Mac. I mean more even than in Windows lol. Like @demberto said above Presonus has developed a cross-platform C++ framework with complex GUI features. But still is developed and first tested in Windows. DAWs are one of the very few fields where very complex cross-platform GUIs are developed with C++.

Ableton does half of the same, but they use the Qt framework as the foundation, including the GUI. I'm sure they've added improvements, and of course all the DSP related code.