Re: [linux-audio-dev] LADSPA GUI Issues (not just GUI, really ;)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST