Re: [linux-audio-dev] LADSPA GUI Issues

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

Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: pe maalis 10 2000 - 12:23:29 EST


On Fri, 10 Mar 2000, 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.

This has been my policy with ecasound. All controllable
objects/parameters must be able to handle any control value.
This makes the runtime system crash proof - ie. no matter which
objects are connected, or what values are given by the end-user, system
will not crash. All other policies (suggested value range, validity
tests, etc.) are optional.

> I suppose what I'm saying is I don't want to the PVR implementation or API
> to go anywhere near the LADSPA API itself. For instance, now that the MN

Same here. Thinking in OO-terms, a plugin+GUI inherits both the plugin
base class and the GUI base class (multiple inheritance that is). Let's
say we have an object of this type. The engine/host side sees it as a
normal plugin object (a realtime thread calls run(), init(), etc.).
At the same time, the GUI event handler sees the same object as a GUI
object, and calls the GUI-related functions. In the end, all
communication between the GUI and the plugin side is done internally
by the plugin object.

I've been writing heavily-OO code for years now, so I'm not the right
person to convert the above OO-model to C. Still, I'm pretty sure it's the
right one. I guess we should have GUI-toolkit specific wrappers
for the LADSPA API. All plugin ports would be handled by the GUI side,
while hosts would see a normal LADSPA plugin without any ports.

> 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

Hey, this is a good idea. I'll add this to ecasound's effect API right
away! ;)

-- 
Kai Vehmanen <kaiv_AT_wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux multitrack audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav


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