Subject: Re: [linux-audio-dev] Mustajuuri -> LADSPA plugins.
From: David Olofson (david_AT_gardena.net)
Date: Sun Apr 01 2001 - 21:23:40 EEST
On Sunday 01 April 2001 17:18, Paul Davis wrote:
> >> you're talking about reimplementing everything that Motif, Xt,
> >> GTK+, Qt, FLTK, XForms and many others have done.
> >
> >No. I'm talking about wrapping low level rendering APIs, such as
> > the X protocol, fbdev direct rendering, Win32 GDI, SDL + various
> > graphics primitive libs, the lower levels of GDK etc etc.
>
> which is *precisely* what GTK+, Qt, FLTK and XForms do: they wrap a
> *low level* rendering API with a higher-level one that is actually
> useful to most people.
In that case, "wrapping" is probably the wrong word; I'm not
intending to raise the level of the API, as that is exactly what has
proved to always fail to deal with the issues I'm thinking about.
Anyway, "most people" wouldn't bother using this interface anyway.
> being able to draw lines on the screen gives
> rise to GUI's like the one for KeyKit. If thats what you want,
> fine.
We'd better just *force* all plugin writers to use "real" toolkits
then - if they can't be trusted writing their own custom rendering
widgets of the kind seen in some DirectX and VST plugins. ;-)
> >> if you want to do something like this, then reimplement
> >> libvstgui, which seems to be pretty adequate for the win/mac VST
> >> plugin crowd.
> >
> >If it's "pretty adequate", why is it bypassed in favor of
> > rendering directly using the underlying rendering API...?
>
> its not. my impression is that 99% of all new VST plugins use
> libvstgui. there are many that don't because they were written
> before libvstgui was developed.
Ok. If you're right, I guess someone *should* be designing something
like that. I just never could imagine how it could solve enough
problems to be warranted, but perhaps it does. In that case, I'm only
getting more and more sidetracked here; my original idea *was* to
implement something like libvstgui...
Well... Say we had (something like) libvstgui. The only thing missing
(unless all of us are missing the point entirely) would be a low
level rendering API for custom rendering of parts that can't be
implemented using the normal widgets.
My proposal would then be implemented as a canvas widget of this
libvstgui style toolkit, allowing plugin GUI writers to do custom
stuff without entirely dropping the toolkit in favor of something
else, less compatible and less portable.
> >I'm not talking about implementing a GUI toolkit (because *that's*
> > a total waste of time, if anything, it seems, at least when it
> > comes to plugin GUIs), but rather something truly portable to use
> > for custom rendering GUIs and *possibly* some existing toolkits,
> > like GTK+ and Qt.
>
> why?
Good question... Provided the libvstgui idea really works, I think I
know what to plan for in the long term - as well as where my canvas
widget should be implemented.
(Oh, why port some toolkit? Well, that's would probably be our
"libvstgui". Just turn it around and implement the toolkit on top of
the canvas API, and my original remark might make some more sense.)
> >Yeah, right; perhaps I should implement the X protocol on top of
> > SDL instead - or just make sure to stay away from closed source
> > plugins that won't run without X.
>
> look: every time someone develops a toolkit, its theoretically
> independent of the underlying rendering system.
Theoretically, yes... That seems to be the problem here. (Apart from
the fact that we need libvstgui, not GTK+ or Qt.)
> it just so happens
> that very few toolkits have taken the step of providing an
> implementation that supports more than 1 rendering system (i.e. the
> X Window System). Recently, Qt and GTK have done just that, and I
> applaud them for it.
Yeah, nice work. However, unless these efforts allow every GTK+ or Qt
plugin GUI to run without X, the problem still isn't solved.
> But that doesn't provide much support in my
> mind for developing something that (1) is so low level that anybody
> that uses it has to do all the stuff that the "toolkits" do anyway
> OR (2) is a toolkit.
I agree about (1). Points out very clearly that if there is to be a
canvas widget of the kind I'm thinking about, it *has to* be a part
of a complete GUI toolkit.
As to (2), is this a matter of "no one will ever take the time to
implement it as Free/Open Source software", or is it "please, not Yet
Another Toolkit?"
Seriously, I don't believe in using any of the existing X toolkits
for plugin GUIs in the long run, especially not if we're supposed to
eventually compete with Win32 and Mac OS based audio/music solutions.
There's probably never going to be a catch-all plugin GUI solution,
but I think it's possible to get *very* much closer than GTK+, Qt etc
etc, and that without writing something huge that noone will have the
motivation to port to something that's not X. Could "libvstgui"
(possibly with some low level canvas widget) be that solution?
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 16:00:24 EEST