Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: David Olofson (david_AT_gardena.net)
Date: Sun Mar 26 2000 - 04:51:45 EEST
On Sat, 25 Mar 2000, Kai Vehmanen wrote:
> 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.
That's what I thought... UI. (And everyone should know what think
about UI code in the processing part of the plugins by now. ;-)
> >> 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.
Yes, there would be too much fun otherwise... *hehe*
> Hosts can check for compatibility.
Fine, but there's still two issues:
1) How do hosts convert data when needed? (That is, if not
all plugins are available in the desired format.)
2) What about formats that the host doesn't understand, and
doesn't need to understand just to host the plugins?
I have solved these issues by "versioning" the ports, and allowing
plugins to use multiple formats at once. Conversion can be done by
normal plugins, so you can avoid doing that in the host, and still be
able to run *any* existing or future plugin.
> >> (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.
Why worry about it at all? Make converter plugins possible, and you're
safe. Optimizing hosts for the major formats, and providing (binary)
plugins for the same formats is recommended, but not required.
> >> 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.
Of course, but at least the flag indicates that the plugin *should*
be able to instantiate in real time, and if it behaves badly, it's a
*bug* that should be fixed in the official version. And if there's no
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
either...
> >> 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.
Yes it is, unless every single user of systems allowing third-party
plugins is supposed to check this list, and understand what it means.
At least, this flag can allow hosts to warn about plugins that aren't
even supposed to have this capability. It can't protect agains bugs,
of course.
> >> 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).
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.
> > 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?
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.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sun Mar 26 2000 - 07:52:33 EEST