Subject: [linux-audio-dev] Re: LADSPA GUI [was: New LADSPA Version - Issues Resolved?]
From: maarten de boer (maarten.deboer_AT_iua.upf.es)
Date: to maalis 09 2000 - 14:06:27 EST
> >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 ?
:-) Never looked at it that way. I guess the use of macintosh in the
past has brainwashed me a bit.
>> [...]
> 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).
Really? That seems strange to me. All these threads.. I'd prefer
one centralized GUI thread.
> >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
Why? The human eye has a lower sampling rate. 30 Hz should really be
enough.
> 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.
Hmm. I never used multiple threads for a GUI, so give me some time
to deal with this concept..
> >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
Maybe we are using a different concept of 'host' here. I ment by host:
the whole application, where you seem to mean just the plugin handling
thread.
> 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.
Right.
> 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.
wow.. that won't be easy..
But what is the problem with GTK? If the plugin's GUI has it's own
main loop, and the hosts GUI passed all events fot the plugin's GUI's
window to that main loop, where would that fail?
> Either way, I don't think that GUI provisions have any place in LADSPA
Except for the discussed event dispatching / X window assignment
> and I don't think that handling X events is something that should ever
> happen in the (main) host thread.
Of course.
Maarten
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST