Subject: [linux-audio-dev] ladspa gui recap
From: David Benson (daveb_AT_idealab.com)
Date: Wed May 31 2000 - 06:45:00 EEST
I would like to state how I see
the ladspa situation in order to fuel
discussion of more specific problems.
0.
there are really two types of guis:
- those which can be composed of xml
- those which would render themselves using a toolkit
i think ladspa will have to support both
mechanisms to reach consensus.
1. xml
the base support required for the xml widgets should probably
be fairly limited to suit minimalist hosts:
- pixmap background images
- controllers, "knob/sliders", buttons, toggle buttons.
2. the toolkit style plugin
there are two ways to approach the "toolkit" problem
(A). vstgui-like api: make an interface the host must
implement (and provide libraries for common toolkit eventually)
(B). native api: support whatever toolkits you like explicitly
in each plugin.
we may wish to support both, but i personally vote for (A)
to be the primary focus, since (B) places an
*incredible* burden on plugin authors and fractures the standard
quite a bit.
(A). vstgui-like approach
- primarily the obstruction here is the perceived
or actual difficulty of making such an api
(B). native approach
the best suggestion thus far for gui plugins
which explicitly support N-toolkits
seems to be (due to benno):
- run each gui-toolkit in a separate process
(maybe thread), so their main loops
can coexist.
although i'd propose that
- run each such gui plugin in a separate process
is likely to be more robust, this is clearly
up for debate.
This is a call for comments -- i am hoping we
can hone in on these points -- particularly,
we could begin moving in the direction of 2A or 2B
if we decide this is good.
Consensus on at least some xml support
seems fairly strong, but if you *object* this
is certainly the time.
- dave
This archive was generated by hypermail 2b28 : Wed May 31 2000 - 07:11:16 EEST