Goodbye VST2

[mike@overtonedsp]

... directly shipping C++ interfaces...

Is not so bad really - I think I understand your objections, but - VST2 relies on C++ too, and, polymorphism and class inheritance are actually quite an elegant way to manage an extensible plug-in API. The main objection I would guess would be compatibility issues, which generally holds better with pure C than C++ (but mainly because the C library hadn't changed... much - until.. of course the recent gcc5 etc compatibility issues).
My plug-ins have always been C++ (even the old LV2 variants, because, as soon as you get into e.g. the GUI code, it makes complete sense to use an object oriented architecture and I didn't want to re-invent the C++ 'wheel' so to speak).

So far (not wanting to tempt fate) they have enjoyed good compatibility with different linux distros, host applications etc. If you are trying to build (especially binaries) to run on anyone else's system other than your own, it is a particularly special challenge on linux, and C++ is quite low down the list of issues.

I've actually just built a linux VST3 version of one of my plug-ins, and so far it seems to work just as well (without needing to use cmake, or requiring any vstgui / GTK dependencies - which is nice)

[Drumfix]

VST2 is plain C. There is no need to use even a single C++ specific instruction.

[mike@overtonedsp]

...There is no need to use even a single C++ specific instruction...

Perhaps its possible - if you have enough time to waste - but, the SDK, for example - audioeffect.cpp and audioeffectx.cpp might point to a more C++ oriented way of approaching VST plug-in development. Anyway - my main point was, it makes not that much difference, there are far bigger and more challenging problems to worry about (especially) if you developing for linux.

It doesn't really matter what the plug-in API - VST2, VST3, LV2, AU LADSPA, etc etc...

same shit, different bucket.

[Drumfix]

The total mess with regards to VST plugin UIs on linux is a excellent example of what happens if developers don't follow the default implementation described in the specification, which was for the host to use the Xt Toolkit and provide an XtWidget in the effEditOpen call on SGI/UNIX/Linux platform.
What makes things worse is that each of these non-compliers state the wheel they invented was the correct way to go.

[mike@overtonedsp]

The total mess with regards to VST plugin UIs on linux is a excellent example of what happens if developers don't follow the default implementation described in the specification...

Actually the specification was that the host provide a 'parent' X11 Window ID to the plug-in when it requests the plug-in's editor to open. The plug-in editor then creates its own X11 Window and reparents it into the host supplied window. After that, the plug-in can use whatever method it likes to render into its X11 Window. The Xt toolkit was an aspect of VSTGUI which was a convenient abstraction provided by the SDK.
The 'mess' is what happens when developers then decide to use GTK, Qt or whatever on top of that because they don't want to deal with X11 directly, or they don't know what they are doing. If you just take the rational and sensible approach that "I need to render into an X11 Window, so I should create some X11 based UI code which does that" it generally works - though there are some particularly special aspects of X11 which can be tricky.
I believe frameworks such as JUCE do exactly this, and are used by the majority of cross-platform / linux VST plug-ins. I chose not to use JUCE, so I built my own X11 based GUI engine which similarly abstracts most of the day to day tasks away from dealing with X11 code directly.
Similarly on linux, at the core VST3 is just expecting an X11 Window (or an HWND on Windows, or an NSView on Mac) though the framework itself provides a means for any platform-specific UI type to be accommodated. Once you've set that up you can render into it however you want to, or, you can use the VSTGUI abstraction if you don't want to deal with the UI at a low level.

(This is also an example of why C++ is a good fit - for example you can then just inherit the base SDK provided editor, and extend it to provide your own GUI)

[Drumfix]

No, it never was a X11 Window ID. If it weren't a XtWidget (at least this was Steinberg's own interpretation of "system dependent window handle"), the examples in the VST SDK would have never worked.

[Lyberta]

Why would people hardcode X11 anyway? X11 is set to be dead soon and Wayland is the future.

[mike@overtonedsp]

No, it never was a X11 Window ID...

Code: Select all

class AEffEditor...
virtual bool open (void* ptr)		{ systemWindow = ptr; return 0; }	///< Open editor, pointer to parent windows is platform-dependent (HWND on Windows, WindowRef on Mac).

Its actually a void pointer, so it can be just about be anything you want it to be. So are you saying that my, and every other linux VST plugin, works by magic then?

The point being, and this goes back to the whole C / C++ thing, that with the magic of C++ you can inherit the base Editor or a descendant, which means you can use X11 if you want to, and expand the base class functionality to implement whatever features you want, which is basically what VSTGUI is doing. Or, you can jump straight in and use VSTGUI (though not that many professional plug-ins do so directly) in which case you get to play with, and depend upon Xt widgets.. good luck with that.

Why would people hardcode X11 anyway? X11 is set to be dead soon and Wayland is the future...

Because that's what works now. There's nothing to stop you writing a Wayland GUI than no-one can use if that's what you want to do - I did mention that the VST3 API actually allows the host to request any type of platform-specific UI in theory, and if the plug-in supports it then it can provide it, so I guess there's nothing to preclude Wayland or whatever comes next being used in the future. Its not hardcoded to X11 that's just the only practical option at the moment.

(and isn't this thread in the wrong place.. It seems to have become a plug-in developer thread - for some definition of 'developer'..)

[Drumfix]

Its actually a void pointer, so it can be just about be anything you want it to be. So are you saying that my, and every other linux VST plugin, works by magic then?

Bullshit. It can absolutly not be anything you want it to be.

Your plugins work because you, like any vst host ever written for linux, are violating the VST specification.
There was no mention ever anywhere in the VST specification about the use of the X11 WIndow ID as the parameter to effEditOpen.

If i write a VST host and supply a void* in the call to EffEditOpen to your plugins they magically crash.
If i try to run the reference implementation of a VST plugin from the VST SDK it crashes in any linux VST host.
Funny, isn't it ?
These two examples completely negate your statement.

The whole X11 Window ID mess started with this post on the linux developer mailing list by the developer of energyXT:
https://lists.linuxaudio.org/archives/l ... 14326.html

Then, when energyXT was available, every linux vst host/plugin developer wanted to be compatible with it...

[mike@overtonedsp]

It can absolutely not be anything you want it to be.

Yes it can - at a fundamental level its e.g. a 32 or 64bit entity (depending upon the processor arch etc). That could represent a memory location in the case of a pointer, or it could be some arbitrary value, in which case it could be, for example an X11 Window ID. In this particular case the issue is how the plug-in interprets it. My (and every other linux VST) plug-in is expecting a valid X11 window ID and will cast the value it receives appropriately and treat it as such. It might crash if you provide a non-existent window ID, or a random pointer than equates to a non-existent X11 Window ID - though I suspect you haven't actually tried it - but that's more due to X11's default error handling behaviour (which is to quit the application) rather than anything to do with pointers etc or a fault in the plug-in.

I don't care how we got to VST2 being the way it is on linux. It is the way it is now, and has been for about the last ten years at least. If you want to make plug-ins that don't work in any host application, but conform to your interpretation of the standard that's fine. I prefer to make things people can (and do) actually use.

[Drumfix]

Other than you I am not interpreting anything. The reference implementation clearly says

Code: Select all

bool CFrame::initFrame (void *systemWin)
        ...
	window  = XtWindow ((Widget)systemWin);
	pDisplay = XtDisplay ((Widget)systemWin);
	...

so that void * must be castable to the Xt Widget type.

My own plugins are perfectly compatible with any linux VST host, simply because they run their GUIs in separate processes unknown to the host. And by doing so i have non of your problems, and don't need to "waste my time" on making them compatible.

[mike@overtonedsp]

so that void * must be castable to the Xt Widget type.

If you want it to be. What you are quoting in your example, is from VSTGUI, which as I've been at pains to point out is (albeit an SDK provided) abstraction from the base Editor. The base editor takes a void* ptr as its parameter. This can represent anything you want (to cast) it to. Its fundamentally just a 32 or 64Bit number. That number might represent a memory location, in the case of a pointer, or it could be a number that refers to an X11 Window ID. it depends what the plug-in chooses to understand it as representing. As it stands, and has done for about the last ten years or more, on Windows this would be an HWND, on Mac it would be an NSView, or previously a Carbon Window Ref, and on Linux its an X11 Window ID.

My own plugins are perfectly compatible with any linux VST host, simply because they run their GUIs in separate processes unknown to the host..

That completely contradicts your own adherence to your own interpretation of the VST2 standard. Nowhere does it say that the GUI could (or should) be run in a separate process, and I think its quite difficult for any normal person to understand what made you think that was a good idea. Based on that I think it would be better to say they are equally incompatible with any host, rather than perfectly compatible, since you can't run the (VST2) GUIs in a separate process without compromising the design quite badly. Unfortunately you are (intentionally or otherwise) misrepresenting some quite fundamental things about VST plug-in design and development, to people who might think you know what you are talking about.

[Drumfix]

Apparently you don't know what a host/plugin api specification is all about and how compliance is validated. Any further discussion is a waste of time.

[mike@overtonedsp]

Apparently you don't know what a host/plugin api specification is all about and how compliance is validated.

So you lecture me about how important it is to adhere to your own misconceived idea about some supposed 'standard' specification, that, if it once existed certainly doesn't now, and hasn't for the significant time I've been developing commercially successful products, then you proudly proclaim how you've broken all those 'rules' in your own design, and that this is somehow 'better'.

I've taken the time to share some of the insight and knowledge I have gained during the development of my own software, not to be trolled by someone who "identifies" (to use the language of our time) as a developer, but clearly lacks appreciation of some very basic concepts.

Any further discussion is a waste of time.

Agreed