Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Sat Mar 25 2000 - 23:56:57 EET
On Sat, 25 Mar 2000, David Olofson wrote:
>> 2. Plugins can optionally use capability-flags to describe
>> the ranges it uses (both data and control).
> Who will use this feature if it's optional? Why specify it, and who
> would read it?
Well, everyne who wants to create a generic user-interface for the
plugin. If no info is available, you just assign a text input or
something to the control port. Not very nice, but works.
>> 3. Actual data type (32/64/128bit float) is determined at compile
>> time. It's easy to recompile OS-plugins
> Ok, but how do you keep track off all different versions of
> everything? (Some hosts may not be OS, you may not want to bother
> with sources at all, etc...)
Of course the compile-time options are stored to the plugin.
Hosts can check for compatibility.
>> (or release multiple binary versions).
> I don't think this will happen unless it's *required* that all
> ormats are supported.
Well, that's not an API problem. And really, there aren't
that many formats... With the risk of sounding like B.Gates,
I'd say 32bit and 64bit floats are the only reasonable alternatives.
Plugins can internally use 1024bit floats if they want to, but
for communicating mono-audio, 64bit is enough.
>> For instance, if a plugin causes problems in
>> a realtime-environment (realtime instantation), user just won't use it.
>> It's that easy.
> Not good enough. If a plugin doesn't explicitly say that they can do
> real time instantiation, I'd never put it in an end-user system that
> needs it. Testing is useless, as it doesn't guarantee anything - you
> may just be "lucky" with the test system.
Well, if I need realtime instantation - especially with end-user
geared stuff - I most certainly will want to personally check the
plugins are good enough. I would never trust an API-flag.
>> Hmm, we could use a standard plugin-data-sheet for
>> documenting all plugins (==> the end-user can check the facts).
> A separate source of unreliable information? I don't think so...
> Would be cool as a quick reference when looking for new plugins, but
> nothing else.
What's a reliable source? Yep, without a central plugin testing committee,
you just have to test the plugins yourself. This is not an API issue.
>> 1. OSS-output plugin. I wasn't very enthusiastic about this, but
>> let's say someone wants to write one. Plugin and host side
>> must exchange info about the used sample value range, one
>> way or another.
> What is that info useful for? If the data format isn't reflected by a
> standard format, someone will have to adjust the level or compress
> the data anyway. Doing it in an external plugin means only that the
> host has to keep track of it, and that there will be extra overhead.
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).
> This problem doesn't exist if there is a standard range. Plugins are
> expected to conform to this standard range, rather than the host
> throwing in extra gain plugins all over the place; that's the whole
Yes, I understand this. For plugin-to-plugin communication this is good,
but for most hosts, this is just not very practical. If the plugin
API hides all control data behind a control-data abstraction, hosts
will be unable to help the end-user. As long as users are happy to
do [-1,1] -> Hz, [-1,1] -> seconds, [-1,1] -> dB conversions all the
time when using LADSPA plugins, I guess it's ok.
Can you explain, how are you going to use these plugins? How, and
what things, you will ask from the end-user?
-- 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
This archive was generated by hypermail 2b28 : Sun Mar 26 2000 - 00:30:07 EET