Is making a Plugin SIZABLE a financial one or are the developers just not in touch with real life
Its like they they dont know what the people need and dont think of different resolution and don't care or is it financial grab for an update
it seems very simple other none music software does it
some do it in DAWs

Im perplexed its always been this way from 1980 that plugins are not sizable, did aliens remove the capability

We go to Mars but we cant make resizables WTF

 

it is only possible since about 1-2 years, that is why.

 

One of the really annoying things about music production is that what is standard in other fields is late in coming to music production and often costs a lot more.

 

I'm perplexed that you think plugins have been around since 1980 when Steinberg released the first VST in 1996.

 

This is MS should have fix 30 years ago with win95 magnifier- replacement MS create better zoom- not 800x600- window size 100% 110% 120%- MS upgrade magnifier we have no problem 4k today

 

It is a financial concern because it does take take time. Time = Money. Also one of the things that users always complain about is bloatware in plugins, specially with skeuomorphic GUIs. We want lighter plugins, so this is another thing that devs take into consideration. Lastly, let us no forget that implementation of resizing brings bus. So now the devs and users have to deal with the new bugs as well. Take a plugin designed 10 years ago with a fixed GUI. By now, the dev has been able to work out the major bugs and it is pretty stable. The dev decides to port to resizable GUI. This will cost money to implement and will introduce new bugs that will cost more money to correct. Not every developer is able to do that financially. Indeed, for a company with dozens or hundreds of plugins this can become quite an expense, and sometimes not worth the expense.

 

There are 2 types of resizing: Static & Dynamic, Static is the one were a set of fixed percentages like 50%, 75%, 100% etc. can be set and it gets applied. This could be done in VST2. The second type is Dynamic type of resizing and it is indeed difficult to implement for a complex and custom GUI like plugin UI. There was no proper way to achieve this in VST2, some devs have indeed done it, but if done wrong it can crash the DAW. VST3 made this type of dynamic, grab-with-your-mouse resizing much easier, because in VST3, the plugin can let the host know when it is getting resized. Also to make a resizable GUI, you need to use a modern UI library. Many plugin devs use ancient ones, in which High DPI, resizing, GPU acceleration etc. isn't available (Waves etc.). Just try to imagine how hard it is to scale each button, knob, image and what not there is in the UI each time we try to resize it. Many plugins use images for knobs and buttons, so scaling affects images badly. So devs nowadays use SVG images or draw it with GPU i.e. hardware acceleration. Plus I think many people don't bother really, they are really used to the looks of a particular plugin

 

ungh i honestly hate this, this was never a problem for me when i was on MacOS.. its one of the things i really miss about it, as now im Windows user.
on MacOS even if a plugin wasnt made for high-res/high DPI/retina support, it would still appear in its original ratio to the screen which means it appears blurry BUT - atleast it doesnt appear too small to work actually work with!

I'm starting to blame Windows itself and how it handles DPI scales and ratios instead of the developers... I mean for god sake you cant even fully re-scale the whole system and apps without signing-out and signing back in! its 2021!
if im using my 1080px 100% scale monitor and then unplugging it and using my 4K 250% scale laptop screen alot of things doesnt scale properly, whether thats icons in hidden icons bar and their spacing, text on some apps, and generally apps might look blurry or have small icons...

if only windows could fix how they handle this.... well, that and drivers lmao

attaching two pictures, of two plugin which doesnt support scaling (Omega-N and Diamond 3) VS. soothe2 which does support it.
Windows versus Mac
- - Windows - -


- - Mac - -

 

Have a look at you Macs Screen settings, I bet it is set to scaled and not native resolution.
You can also scale Windows to any number which is not possible under macos, there you can just choose resolutions or on retina recognized screens Scaling factors.

 

oh its my macbook pro mid 2015 retina display, not sure exactly what you mean by native resolution as theres no option for it that i can see?
there are scaling options however, larger text -- default -- more space (and in every setting - plugins scales perfectly).
it was set on Default for display anyhow,

my point is that i never had to care or think about it, unlike Windows, and thats a good UI and UX, the mindset of building a core foundation to support the unsupported...

the scaling on windows to any number i mean sure its nice to have i guess, but how actually usable is it when other apps are not optimized to work for it?
having options is always nice, but having a strong core usability support should be a priority imo

 

Retina supported screen:

Not sure how the scaling works here but I bet it is just 100% 125% 175% 200% etc...
I don't know, anyone ?


Non retina supported screen:




Here we can just select the resolutions under the scaled option, Is that Scaling the same as with a retina supported screen ?

Under Windows 10 Studio One 5 it is working quite good , but you have to enable dpi scaling for each loaded plugin and some do not work well , but most.

 

aha? so your photoshop plug-ins are scalable since 1980?

 

Between @The Pirate and @demberto they mentioned all the important things.
One example of resizable image-based (not vector) VST2 is my beloved TSE Audio X502 ampsim. You can magnify to 150%, 200% and possibly a few more.
But if you don't implement this complex feature from scratch you're fucked. Also as has been said, in Windows the HighDPI support is quite new and still not fully mature.
Yet another one more reason most developers switch to the JUCE framework which is fully vector-based, even the fonts. Which BTW is not the ideal solution for the fonts, but who can blame them after all the problems we are talking.

 

the worst are UAD and their premium price plugins.

 

actually it was quite difficult to make a host tell to resize and reinitialse a window. the few plug-ins which did that 20 years ago failed to do it in most host programs and not even the waldorf plug-ins distributed by steinberg didnt work in the first version of nuendo.

 

It wasn't me who mentioned 1980. I never mentioned resizable anything actually.
And i do not use Photoshop.

 

who can afford the licensing costs

 

Yeah, that sucks.
It's great for open source plugin developers to have a full-fledged free version. Or even a beginner like me who gets to play around making very basic VSTs from time to time.
But they have no competence and they have been raising a lot the commercial licenses over the last years.

And the official VST GUI library is a nightmare. The other day after debating about the Surge synth GUI with a fellow member here I took a look at their source code. I was impressed that they managed to do a complex GUI using the VSTGUI.
But then I discovered a section of the gui code that's literally called "escape from vstgui". Can't get any more clear than that.

https://github.com/surge-synthesize...from-vstgui/include/efvg/escape_from_vstgui.h

Hard to say if it's gonna be a partial or total change with so much work invested. But needless to say which GUI library are going to switch to. You can found JUCE references already in the code.

 

Last edited: Feb 22, 2021

It all really depends on the paradigm used when the plugin was first written as well and how optimized it was.

The newer rendering engines like Metal, OpenGL and DirectX allow for a bit more separation between views/controllers and computation and in general produce smaller packages which can make changes for operating system and or scaling issues trivial for view/controller UX trivial.

The problem is once you are ridding on a donkey cart people generally don't want to or convince themselves that they don't have the time to change their their view/controller UX or are ordered to not mess with it by their superiors and focus on making something else that is new and they can sell rather than improve something that isn't going to generate new income sources.

In a sense a company like FabFilter or DMG might find it completely trivial to change their UI/UX whereas Waves isn't even interested in opening that can of worms. Scalable interface hooks had been available for almost a decade before companies like AVID and Steinberg took advantage of it in their DAWS which is more important than the feature being available in an OS API as stability between DAW and container processes can be affected.

Small companies also don't tend to change rendering engines or change them minimally for the most basic compliance and would rather take a giant leap when they are forced to than small bites when they become available. MOTU works on this principle, its software branch is rather small and it's UIs are MacOS Quartz v1 & v2 derivatives and haven't really been touched since then and you can tell they are almost 15 years old even though some optimizations have been done their UIs are not as responsive or as detached from computing operations as say something like Studio One is. This hanging around of legacy code that just gets ported up over and over is a compounding problem: I'm fat cause I eat when am sad and I am sad that am fat so I eat. So with Apple's recent push to oust Quartz and move to Metal users of Digital Performer should look forward to the once in a score of years UI/UX update.

TLDR

For older companies it is much harder to do this than it is for younger ones, but it is still a pain in the ass and it relies on the host daws as well.