Subject: Re: [linux-audio-dev] audio application mixing/routing arch
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Fri Mar 31 2000 - 21:40:55 EEST
Maurizio DE CECCO wrote:
>
> Erik Steffl <esteffl_AT_pbi.net> writes:
> > 1) the UI for plugins is provided only via host, the plugins tell host
> > what parameters they have and host lets you change them. this makes for
> > nice uniform and consistent user interface but does not leave much
> > control for individual plugins. it is not possible to create plugins
> > that do some kind of visualization...
>
> It is if you use shared memory for communicating, for example.
what I ment is that they exchange parameters, plugin says to host: I
have two check boxes, one slider, the host displays this in its GUI (or
provides other way to view/edit it) and informs plugin of any changes
made. there's no place for customized graphics, only parameters are
exchanged, host decides how it will be displayed (there might be command
line interface, ncurses interface, GUI interface, ...) most plugins that
are audio only (I guess that would be most of the plugins) should work
well enough using this approach, it's efficient and flexible...
> > and I bet there would
> > be few plugins that would simply provide their own GUI since there's
> > nothing you can do to prevent it (but that's not necessarily bad, you
> > might have to do it for performance reasons).
>
> Well, there is the Event queue polling problem; i.e. either you
> poll the event queue manually in the plugin, or you have a parallel
> thread; in the second case, expecially on Linux, you are exactly in
> the situation 1.
no it's not since plugin can open it's own window, svga session, use
DRI etc. and display any graphics it wants, unlike in case 1) where
plugin has no control how/if the actual controls are displayed.
erik
This archive was generated by hypermail 2b28 : Fri Mar 31 2000 - 22:36:38 EEST