Subject: Re: [linux-audio-dev] FW: LADPSA Freeverb - update?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed May 24 2000 - 19:41:28 EEST
>The intent of the above example is that it
>maps into pixels directly, so although it defines
>a toolkit, it is not gtk+ with gtkhscrollbar/gtkpixmap..
>(However it can be built in the gtk+ framework;
>the skin/gtkpixscrollbar in gdam implements the scrollbar)
>
>I intended it to be interpreted as:
>no frames, no padding, all the pixels rendereed
>come from the two pixmaps, foo.xpm and bauble.xpm.
OK, sorry, I had misinterpreted that.
>But yes, interpreting these gui plugins is going
>to require some work -- remember that vstGUI never
>was intended to be ported to other hosts so this
>presumably wasn't a concern...
Well, not really. vstGUI isn't called by the host, and its already
been written for Windows/MacOS/Motif. So its very portable. Its also
C++, which will annoy many people and make it less likely to be used
by all those who "should".
> - force plugins to do all the rendering the work
> (but how can they? they cannot
> be in the same process/thread to do this really,
> unless we force a toolkit on them)
I don't get this. Assume GTK+ for a moment, since at the least the two
of us are very familiar with it. Assume that the plugin provides a
gui_constructor() function, and that the host calls it. It creates a
GtkWindow filled with a bunch of GtkWidgets, and attaches callbacks to
some set of signals for those widgets.
The X event loop will run in its own thread in the host application,
and the plugin's callbacks will be executed from that thread. This
will not be the same thread as the one in which the plugin's
run/run_adding functions are called.
Ah, so yes, we've forced a toolkit on them. But I'm still
investigating methods to make this go away.
> - force plugins and hosts to use a standard interface
> library (reinvents the wheel, but definitely helps
> certain issues)
>
> - force hosts to do the rendering (imposes a great complexity
> cost on hosts) (we must find a way to specify from
> the plugin what it should look like)
>
>I agree that the latter two are equivalent,
>but I think library design carries with it a lot
>of practical responsibility and hard-to-agree on choices (eg language).
>(Making the library *extensible* is even harder...)
Why not start from vstGUI, which incorporates several years worth of
knowledge and experience with this kind of thing ?
--p
This archive was generated by hypermail 2b28 : Wed May 24 2000 - 20:18:24 EEST