CLAP - CLever Audio Plugin

All your LV2 and LADSPA goodness and more.

Moderators: MattKingUSA, khz

Drumfix
Established Member
Posts: 299
Joined: Mon Jan 26, 2009 5:15 pm
Been thanked: 11 times

Re: CLAP - CLever Audio Plugin

Post by Drumfix »

Apparently our needs are quite different :)

1. While i would have liked to have more than one midi port in some of my hardware midi equipment to overcome the low midi bandwidth
i see not a single use case where i would require more than one midi port in a plugin.
2. I see no reason at all, why this should be needed in a plugin.
3. I use an external UI that runs in a separate process. And i don't want the host to mess around with my UI at all (except for opening and closing).
Since all current VST hosts implement the window embedding nonsense i just tell the host that i have no editor at all and make the first parameter
my own gui on/off of switch.
Btw, the term "system specific window handle" does not imply, that this must be an X11 window.
4. VST has sendEventsToHost for sending timestamped events. There is an enum kVstParameterType (deprecated in VSt2.4).
Unfortunately Steinberg forgot to add the related VstParameterEvent structure. This is the one (of three) items that i complain about (and easy to fix).
5. There are VstInputProperties/Outputproperties and VstParameterProperties. Except for the names
6. Please explain. Why should timeinfo change during a process call?
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

external ui, external ui and again: external ui. Its the ignorance of the LV2 advocates that makes LV2 a nogo.

What plugin developers don't like about LV2 has been discussed to death on the LAD mailing list for the last 8 years.
Pointless to discuss all this here again.

VST has (almost) everything i'd ever want from a plugin Api. Things that i don't like about it could be changed within less than a minute,
and they don't even break compatibility to existing hosts or plugins. So, no need to go with anything else.
Yes.

(and many hugely complex plug-ins have been developed to work using VST on other OS. I've yet to see anything even approaching that level of complexity on linux / LV2, and yet there seems a disproportionate amount of extensions to deal with this or that, odd corner cases, for things which would / should - by professional developers - be considered quite basic stuff). I think the most significant issue for VST on linux is / was the (GPL unfriendly) license. I don't know how much LV2 (or its developers) owe to studying any existing standards / formats, though if I had to guess I'd say it leans more towards a kind of poor man's Audio Unit than VST).
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: CLAP - CLever Audio Plugin

Post by tramp »

falkTX wrote: Developing a plugin UI in gtkmm is very stupid and dangerous, I wish devs didn't do it.
I consider them broken.
??
I know that most devs who use QT didn't like gtkmm, but, why do yo think develop a plugin UI in gtkmm is "stupid and dangerous" or "broken".
Note that I've all guitarix LV2 plug UI's written in gtkmm, (true, the widget hand over to the host is gtk+) which problems do you have with them?
On the road again.
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

3. I use an external UI that runs in a separate process. And i don't want the host to mess around with my UI at all (except for opening and closing).
Since all current VST hosts implement the window embedding nonsense i just tell the host that i have no editor at all and make the first parameter
my own gui on/off of switch.
Arrrggh - that's just really horrible. On (anything other than maybe linux) threre's no reason to do this (and doing so will seriously mess with any if not all host integration - if you haven't had a problem with that yet, you will).
For example, on Windows, you render the UI to an HWND, thats where everything will end up anyway, even if you use an external UI you would likely be doing this, its how "stuff gets displayed in a window". So whatever your UI does, you just create an HWND for it, render the UI into it. I don't think anyone really uses VSTGUI much anymore, but you should at least be using the underlying editor API. On other OS, its much the same - on Mac, its just a Cocoa View (create your own custom View based on an NSView, render into it) On Linux, its X11 - create an X11 window, render into it. In each case, your window eventually becomes a child of the hosts plugin window, or a subview, or whatever, but you only need to think about that once, after that, you're just drawing into whatever the 'generic' window / view on the OS is. It doesn't / shouldn't matter to you whether that lives in the host application or not.
I know that most devs who use QT didn't like gtkmm, but, why do yo think develop a plugin UI in gtkmm is "stupid and dangerous" or "broken".
Note that I've all guitarix LV2 plug UI's written in gtkmm, (true, the widget hand over to the host is gtk+) which problems do you have with them?
The biggest problem I've seen with it, is that you have to compile the plugin against the specific version of gtkmm the host uses (if at all) - otherwise you may (will) have problems when the plug-in is loaded (on some machine other than perhaps your computer). In ardour, for example, they pre-package it, with its own libraries, including gtkmm, and change the linker paths etc. so if your plugin dynamically links to gtkmm, you have no way of knowing which version it will be using when the plug-in is loaded in a particular host.. This can (and does) cause subtle breakage. I'm guessing that for guitarix, your plug-ins are compiled to be integrated with the host - i.e. guitarix - therefore they're not really 'plug-ins' but just part of your application, in which case you won't see the same problems (in guitarix anyway).
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: CLAP - CLever Audio Plugin

Post by tramp »

linuxdsp wrote:The biggest problem I've seen with it, is that you have to compile the plugin against the specific version of gtkmm the host uses (if at all) - otherwise you may (will) have problems when the plug-in is loaded (on some machine other than perhaps your computer). In ardour, for example, they pre-package it, with its own libraries, including gtkmm, and change the linker paths etc. so if your plugin dynamically links to gtkmm, you have no way of knowing which version it will be using when the plug-in is loaded in a particular host.. This can (and does) cause subtle breakage.
Well, that's a problem when binary’s get provided outside of a distribution.
I'm a debian guy, and support the DFSG. What you mention here, is on of the reasons for "Distributions" to exist.
I'm not sure about, but wouldn't the same happen in a QT (or what ever toolkit) case of this scenario?
I remember, for example, that Ardour ships together with it's binary builds, a QT lib, witch leads to the same trouble over there.
However, you are right, the distribution of close source Host's and plugins complicate the situation.
linuxdsp wrote: I'm guessing that for guitarix, your plug-ins are compiled to be integrated with the host - i.e. guitarix - therefore they're not really 'plug-ins' but just part of your application, in which case you won't see the same problems (in guitarix anyway).
I talk about the guitarix LV2 plugin suite, not about the guitarix main application.
In guitarix-main, we didn't support Plugin UI's, we ever use our own host created UI for "any" plugins (LV2/LADSPA/gx)
On the road again.
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: CLAP - CLever Audio Plugin

Post by tramp »

falkTX wrote:As linuxDSP said it creates issues if the host uses a different version of gtkmm that the plugin was compiled against.
I've had quite a few problems with gtkmm UIs, but never with pure gtk ones.
As I said, you just need a host binary written in plain gtk, compiled against a other lib version, e voila. The same is properly true for QT.
So, to be honest, you get problems with Host witch are provided in binary format, instead in source format. That, would delete the problems.
falkTX wrote:To me it feels like using KDE libs to develop a Qt UI.
We can do it yes, but I'd prefer not to.
That's Apples and Bananas. KDE libs, are, desktop depend libs, that have nothing to do with gtk+ <-> gtkmm.
gtkmm is just a C++ wrapper for gtk, that's all.
I prefer C++ over plain C.
On the road again.
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: CLAP - CLever Audio Plugin

Post by tramp »

falkTX wrote:I've had quite a few problems with gtkmm UIs, but never with pure gtk ones.
However, I see you've added support for the MOD UI's in carla, maybe you can use the MOD UI's for the guitarix plugs there instead the original ones, (I would prefer them, as they simply looks better) :)
On the road again.
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

As long as developers create UIs without instance-access I'll be happy...
I confess to having to use it on one plug-in, the "legacy" LV2 version of my AF2-10 graphical EQ (new VST versions are fine, and this obviously is not an issue anywhere except linux). Essentially because there isn't / wasn't any other way to transfer the FFT data from the plug-in to the UI in a timely fashion. Using instance access does feel like a hack - but that's not because the concept itself is bad (if it's correctly understood) - more because it goes against LV2's design (but unfortunately no-one has provided an officially sanctioned method which works as well. There might be something possible with "atoms" but I start losing the will to live when I read the documentation...)
That said, instance-access is kind of a redundant issue for me, as the LV2 plug-in in question is no longer actively developed, having switched to linux VST and been much improved, however there will still be users with the old version. This plug-in will 'fail safe' if instance access is not supported, but the FFT will not display.
User avatar
rncbc
Established Member
Posts: 1060
Joined: Mon Apr 19, 2010 12:20 pm
Has thanked: 45 times
Been thanked: 256 times
Contact:

Re: CLAP - CLever Audio Plugin

Post by rncbc »

falkTX wrote:As long as developers create UIs without instance-access I'll be happy. :D
(Rui, we need to talk...)
instance-access has nothing to do with the so called toolkit wars...

instance-access is indeed a show-stopper for any out-of-process views (ie. UI's), yes that's completely true. but as long DSP code (model) stays in-process (ie. same address-space) as the UI code (view) there's no problem or disadvantage to it whatsoever. quite the contrary, or rather an academic one perhaps...

yep, i'm sure hearing the holy ghost of mighty edw's wrath: instance-access considered harmful :)

yep, instance-access is an anti-pattern. but let me say that VST is well fully bloated of those dang evils a lot more than any other plugin spec...

using instance-access (and data-access) is non-advisable to use it on new designs. at least for the ones that might be called "ideal" or, if i'm allowed to be pedantic, "compliant to the highest moral virtue"...

now, we all know that LV2 history has not been always that kind, do we? ;) but don't get me wrong, it is (slowly) getting in the right direction.

cheers
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

..Instance-access is indeed a show-stopper for any out-of-process views (ie. UI's), yes that's completely true. but as long DSP code (model) stays in-process (ie. same address-space) as the UI code (view) there's no problem or disadvantage to it whatsoever. quite the contrary, or rather an academic one perhaps...
Agreed.

I used it in one LV2 because it was the most logical and efficient method to transfer the relatively large amounts of data (only a few K, but more than just a few parameter tweaks) and I expected that most use cases for the plug-in would be with the UI and the DSP would be in the same process. If not, then instance-access may not or could not be supported by the host and that bit of my UI functionality would fail (displays a warning dialogue and the FFT doesn't appear).
With VST(2.x) this kind of instance-access thing is almost part of the spec, since the Editor:: and Plugin DSP:: are really just two classes instantiated for each instance of the plugin. Each has a pointer to the other and they were never intended to be on different machines / or out of process.
Accessing the UI (Editor) instance from the plugin DSP instance or vice-versa isn't the 'prefered' option obviously - but if you do, it resolves to nothing more than calling a class member function from another class member function, which is entirely normal.
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

Please take a look at...
Yes I'm familiar with that work - but as I said it's kind of a redundant point for me because I don't expect to be doing any future work with LV2 - at least not with the LV2 version of the EQ plug-in I mentioned. There is a much improved version which works just fine as a linux, Mac and Windows VST, and which I think is a great piece of work, but to be honest, while this latest version has proved popular on other platforms, the original LV2 version was largely ignored by linux users, which means, sadly that it is difficult to justify the developer time and effort (and expense) to develop the older LV2 EQ plug-in further. I mention its dependence on instance-access more as information for host developers, and in that there are some plugins which do use instance-access and on which (a few) users might still depend.
User avatar
rncbc
Established Member
Posts: 1060
Joined: Mon Apr 19, 2010 12:20 pm
Has thanked: 45 times
Been thanked: 256 times
Contact:

Re: CLAP - CLever Audio Plugin

Post by rncbc »

falkTX wrote:
rncbc wrote:
falkTX wrote:As long as developers create UIs without instance-access I'll be happy. :D
(Rui, we need to talk...)
instance-access has nothing to do with the so called toolkit wars...

instance-access is indeed a show-stopper for any out-of-process views (ie. UI's), yes that's completely true. but as long DSP code (model) stays in-process (ie. same address-space) as the UI code (view) there's no problem or disadvantage to it whatsoever. quite the contrary, or rather an academic one perhaps...
I know that instance-access has nothing to do with "toolkit wars".
For me it's about showing plugin UIs safely.

Not sure if you know but Carla runs LV2 UIs in a separate process whenever possible.
This allows it to mix all sorts of toolkits (gtk2+3, qt4+5, etc etc), without crashing anything.
With instance-access this is no longer possible.
i know that is not possible. i've just stated that above.

but my plugins won't drop instance-access any day soon. why? sorry for my french, for crying out loud, i don't give a damn. it would make a whole lotta PITA to code it all over through lv2 atom, worker, schedule and what not. as is, currently, it simply works. and it is not broken. so i don't feel the urge to fix it :)

you can move to qt5 any day, any time. it's your call anyway. my plugins are qt5 ready. today. ditto for qtractor. once they are build on qt5 they will show up as lv2ui qt5 uris, and thus, you as a host, may opt to instantiate the UI as either using the lv2_external_ui or by means of the lv2_show/idle interfaces--there's nothing to do about preventing instance-access whatsoever--it's YOUR call to stop supporting plugins that make use of it or in-process UIs. not mine.

cheers
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: CLAP - CLever Audio Plugin

Post by tramp »

falkTX wrote:
tramp wrote:gtkmm is just a C++ wrapper for gtk, that's all.
Except that gtkmm has init methods separate from gtk, and if a plugin or host doesn't call them bad things will happen.
The same is true for KDE libs.
KWidgets expect a KApplication to have been constructed instead of just QApplication.

Anyway, I don't have reasons to complain about guitarix UIs so far (I didn't know they were gtkmm).
My past experiences with gtkmm UIs made me have a bad opinion about it, but I guess what was broken was the UI code.

As long as developers create UIs without instance-access I'll be happy. :D
(Rui, we need to talk...)
Well, it's easy to do something wrong, no matter witch toolkit you use. The same is true for Plugin Specs, again no matter witch one you use. :wink:
To init gtkmm we just call
Gtk::Main::init_gtkmm_internals(); to set up the g type system and the Glib::wrap() table
There is no fancy stuff about init gtkmm like you have with KDE libs.
Maybe you didn't notice that gx_plugs use gtkmm because we hand over a gtk+ widget container, witch contains the gtkmm widgets, to the host.
On the road again.
Drumfix
Established Member
Posts: 299
Joined: Mon Jan 26, 2009 5:15 pm
Been thanked: 11 times

Re: CLAP - CLever Audio Plugin

Post by Drumfix »

LOL, reading all this here and seeing all the problems people have with hosts fighting with the plugins for who can use the keyboard and such
(this is not limited to linux) i would have to be completely mad to not use external uis. And this does't even include the bonus of being able to use the plugin with a headless
host and displaying the gui on a completely different machine. I know, the latter is just a corner case though.
ssj71
Established Member
Posts: 1294
Joined: Tue Sep 25, 2012 6:36 pm
Has thanked: 1 time

Re: CLAP - CLever Audio Plugin

Post by ssj71 »

Drumfix wrote:LOL, reading all this here and seeing all the problems people have with hosts fighting with the plugins for who can use the keyboard and such
(this is not limited to linux) i would have to be completely mad to not use external uis. And this does't even include the bonus of being able to use the plugin with a headless
host and displaying the gui on a completely different machine. I know, the latter is just a corner case though.
? I don't understand your meaning at all. This whole discussion is revolving around implementation of external UIs. By not separating the DSP and UI you cannot do headless setups at all. And why must one be mad to not use external UIs? All my plugins so far are 100% functional with host generated UIs. I understand this is not the case for all or even most plugins, but there are many cases where a few sliders are sufficient.

I don't see whats wrong with a developer community trying to persuade each other to what practices are appropriate and will make the ecosystem perform well and be stable. The way I see it if hosts can run my plugins more safely by separating the UI and DSP processes, they should. Plugins that are the exception to this create a scenario where hosts can't do this and may not bother implementing it this way at all since they'd have to do both implementations. That affects every other developer.
_ssj71

music: https://soundcloud.com/ssj71
My plugins are Infamous! http://ssj71.github.io/infamousPlugins
I just want to get back to making music!
Post Reply