Subject: [linux-audio-dev] Re: LADSPA GUI [was: New LADSPA Version - Issues Resolved?]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to maalis 09 2000 - 13:49:12 EST
In message <00030919195901.29150_AT_mtg150.upf.es>you write:
>> I think this is an exceptionally bad idea. the vstGUI model is all
>> wrong. The only way that a host might conceivably get involved with
>> providing a GUI to a plugin is to give it a handle to either an
>> XWindow, or if the host was toolkit-specific, some toolkit specific
>
>On the other hand, providing a basic set GUI functions has also
>some advantages
>- unified look & feel
>- memory footage
>- compatibility issues (and possible crossplatformness)
Definitely, but this should be done in a library, that can be
dynamically linked to by the plugin. It has no place in the host.
As for "unified look & feel" - thats as bad as people here in the USA
who want "prayer in school". Whose prayers ? What day of the week ?
What time of day ? I think that we should allow plugins with GUI's to
define their own look, but make it as easy as possible for them to use
a common set of widgets *if they use the relevant toolkit*.
>> widget. GTK has a fairly nice "GtkSocket/GtkPlug" pair of widgets just
>> for this kind of purpose. Sharing a connection to an X host makes a
>> little bit of sense (though actually, not much, because very few X
>> servers are truly MT-safe, and the GUI code does not and *cannot* be
>> allowed to run in the host thread).
>
>I don't understand this very well.
>Don't you mean in the plugin thread?
No, all plugins run in the host thread, in an order determined by the
host. If plugins ran in their own thread, there would be all kinds of
synchronization nonsense necessary, and very close to zero gain, since
they *have* to run sequentially in almost every useful instance.
Plugins may create their own thread(s) as well, for example to manage
their GUI's, or to handle I/O with other devices (e.g a MIDI port).
>Anyway, there should be a seperate GUI thread, that's for sure.
>So, how would an osciloscope plugin work? This is how I would
>do it. The osciloscope copies it's input into a circular buffer
>that is big enough so that writing in it (copy from input)
>will not interfear with reading from it (displaying it). The
>graphical stuff is called periodically from the gui thread, and
>that's it. Does that seem the correct approach?
Right. Well, almost. I would give the plugin its own GUI thread, and
have it periodically update the graphical display. There's no point
trying to duplicate the kernel's own timeout code with a user-level
version, and these plugin GUI threads may run at quite different
speeds from each other. I have meters on ardour that attempt to run at
roughly the screen update rate (say, 70Hz), but other visual elements
that only need updates every 0.5 or even 1.0 seconds. Since the kernel
will take of this for us, we should use it, I think.
>The host should pass raw X events to the plugin, and the plugin
>passes these to the appropiate event dispatch function of the
>GUI library it uses. I think FLTK can do this with no problems.
>And no MT-safety issues here, right?
Wrong. The host should not be paying attention to X events. What role
does it have there at all ? However, we have to get realistic. X does
not really allow multiple connections to the same host from within a
single task (process), so there has to be something that owns "the"
connection to the server. The only logical choice for this is the
host. But the host thread should not be doing anything with
GTK. Remember, LADSPA has no provision for "events" of the kind you
are describing. So instead, I think that GUI-friendly hosts should run
a GUI thread that does more or less what you describe.
I am not sure that GTK has any provision for handling X events other
than by using its own main loop code, and it will definitely break
other aspects of GTK to not run the main loop. So instead, what I
think would have to happen is that we'd have to add an API for GUI
plugins whereby they end up with a pipe that looks like the connection
to the X server. This all needs a lot more thought.
Either way, I don't think that GUI provisions have any place in
LADSPA, and I don't think that handling X events is something that
should ever happen in the (main) host thread.
--p
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST