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: Sun Mar 26 2000 - 16:09:05 EEST


On Sun, 26 Mar 2000, David Olofson wrote:

> 1) How do hosts convert data when needed? (That is, if not
> all plugins are available in the desired format.)

They don't. This is why we have just a few format (32bit and 64bit
float). You recompile, load another .so file, contact the plugin
author, whatever... Converter plugins just slow down processing
and make things more complex to setup.

> 2) What about formats that the host doesn't understand, and
> doesn't need to understand just to host the plugins?

There aren't any. Of course, if we want to support multiple
formats (audio, video, background hiss from from outer space, etc),
my approach doesn't work, but I'm not sure if I want that.

> flag, how is the unknowing end-user going to understand why some
> plugins screw up the sound for no obvious reason? The host can't tell

He checks the plugin docs (the standard plugin doc-template
I mentioned earlier). We can put a separata RT-section there.

>> OSS-plugin specifies input and output bounds for its data port.
>> It will then use these values for converting to the incoming sample data
>> to a suitable format (8bit, 16bit, etc).
> Using a non-specialized API, I'd do this by specifying different
> input and output data types, and/or by telling the plugin what to do
> through control ports.

And force host to convert to 8bit signed? The latter option requires
an event system. I really don't think that mixing sample formats is
a good thing. If everything uses the same format, everything is simpler.
In a closed environment, I understand that plugin converters and
multi-format support is needed, but hey, this is open-source! If I
really like some plugin, I rather get an format-matching version of
it than use converter plugin and thus get worse performance.

>> Can you explain, how are you going to use these plugins? How, and
>> what things, you will ask from the end-user?
> What's wrong with providing a separate file describing this? That
> way, advanced users or sysadmins can edit these files in order to
> use different units, plugin developers can provide description files
> with multiple sections (US, european, different languages etc) and so
> on... A simple library (for both dynamic or static linking) should
> come with the SDK, so that host developers don't have to deal with the
> details.

- added complexity for both hosts and plugin writers
- we need another spec (for the file format and the SDK)
- more scaling... host scales from 'real-meaning' -> [-1,1] and
  plugins scales [-1,1] -> 'internal-representation'
 

-- 
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 : Sun Mar 26 2000 - 16:05:21 EEST