Subject: Re: [linux-audio-dev] LADSPA GUI Issues (not just GUI, really ;)
From: Alexander König (alex_AT_rhlx01.fht-esslingen.de)
Date: la maalis 11 2000 - 08:46:56 EST
on the subject: as Kai Vehmanen has shown, value ranges are *not* GUI
specific.
I hope it's okay when I sum up things a bit before I get to one more
question...
"Richard W.E. Furse" wrote:
<..>
> (2) The plugin should provide enough information to the host so that the
> host can make up a useful plugin visual representation (PVR) automatically.
> However, the plugin should behave sensibly whatever signal or control data
> is received. This may require the plugin to do range checking on
> parameters.
Yes, although the range checking is unecessary for the host->plugin
situation, if the host cares about the "useful" range it's still
required when connecting some plugin's output port to another plugin's
input as Paul Barton-Davis has shown.
<..>
> It MIGHT well be worth setting up a GUI API for LADSPA plugins for X-Window
> if there is a consensus on how this should be done. Because of the variety
> of graphical toolkit out there I suspect we might be better off leaving
> this for the moment, but if people can agree on a common standard that
> would be very cool. Even so, I'd like to avoid clouding the issue too much
> with LADSPA and for the GUI API to be separate.
I strongly agree on that. Including the value range in the code doesn't
say we couldn't provide another way how a plugin could tell the host
what kind of GUI it wants - and that surely doesn't belong in the
ladSIMPLEpa API ;)
<..>
> although I prefer the idea of toggles being off if <=0 and on if >0 - this
> allows clever things to be done by connecting control LFOs to toggle
> control switches etc.) Note that this is only a *suggested* range. The
> plugin is expected to accept ANY value as in fact the user may have plugged
> in a control signal rather than entering a value (depending on host
> behaviour) and will be rather annoyed if the entire application then
> explodes. I've mixed feelings about all this - what do other people think?
As you can imagine, I'd be happy with a solution like this ;) And your
toggle implementation is much better.
But now for the other thing I wanted to ask: Let's say we have something
like a LADSPA-OSS-output plugin. How should that behave? My concern is
on locking /dev/dsp for example. I see 3 ways this could be handled:
1 - with the current design the plugin would have to open /dev/dsp in
instantiate() and closing would be done in cleanup() then. This would
result in a blocked /dev/dsp (with oss drivers) while there is a plugin
instance - no matter whether the host actually plays audio or not.
2 - we could have two extra functions like start()/stop() but that might
be an overkill for a simple API.
3 - this could be managed with some dedicated control ports - but if we
want to do it this way we should define how these control ports have to
work.
Now before this results in OSS discussion: I guess there are some other
important resources that should be blocked by a plugin only when it's
actually busy - but just like with the value range I can't think of an
example right now - any suggestions, Kai? ;)
IMHO output plugins are very important. At least I get lot of requests
like "Why doesn't your app support my output system?"
Alex
--
________________________________________________________________________
Alexander König - alex_AT_42.fht-esslingen.de
http://www.terminatorX.cx
[From the Homer Quotables:]
All right. His story checks out.
-- Homer Simpson, checking in the encyclopedia
under "Bush, George"
Two Bad Neighbors
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST