Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: David Olofson (david_AT_gardena.net)
Date: Thu Mar 30 2000 - 06:36:30 EEST
On Sun, 26 Mar 2000, Kai Vehmanen wrote:
> 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...
Ok; maybe I've had to deal with too much closed source/proprietary
crap before I started to use a real OS, but this attitude worries me
a little.
> Converter plugins just slow down processing
> and make things more complex to setup.
Yes, but they make the setups possible to do.
> > 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.
This won't work. Users (especially the ones without a healthy UN*X
background) don't read docs first, but rather call the support line
when nothing seems to work. (I have experience with this...)
> >> 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?
Yes, if the host insists on doing the OSS I/O itself, and there is no
multiple data format support in the API.
> The latter option requires an event system.
Yes, (or at least a way for a plugin to tell the host that it'd
like to change it's output data type - the messy way), unless the OSS
plugin does the OSS I/O.
> I really don't think that mixing sample formats is
> a good thing. If everything uses the same format, everything is simpler.
Yes. The world would be a lot simpler if all humans were alike as
well...
> In a closed environment, I understand that plugin converters and
> multi-format support is needed, but hey, this is open-source!
Who says? I'd prefer to use only open source software, but I'm afraid
plugins are to similar to art for this to happen. It doesn't work
well for games for about the same reasons.
> If I
> really like some plugin, I rather get an format-matching version of
> it than use converter plugin and thus get worse performance.
What if you have to get you job done and the plugin isn't available
in the format your host is using? Some people make their living on
getting that right sound at all times.
OTOH, there is TDM, VST, DirectX etc, none of which provide any
special advantages as an API. They're just different APIs doing about
the same thing. The API jungle can't be eliminated with an API that
many developers are unhappy with.
Then again, it's impossible to design The Perfect API for all needs,
so sometimes one starts to wonder what point there is with all this
anyway... Anyway, I'm doing it because I just can't stand wasting
fine hardware on an OS with yesterday's RT performance and still get
pissed off by BSODs and reboots all the time. I might be wasting my
time, but at least it feels better.
Uhm, well, back to the topic.
> >> 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)
Yep, you can't have everything for free...
BTW, what about the custom (G)UI API? This is a separate issue
regardles of how this one is resolved.
> - more scaling... host scales from 'real-meaning' -> [-1,1] and
This is only done for GUI stuff, which is pretty low bandwidth
compared to the audio processing.
> plugins scales [-1,1] -> 'internal-representation'
Most processing algos have linear response, so no scaling is needed.
Plugins with non-linear responses simply adapt their constants to
the standard range, just as they would have to do with any range.
Note:
Of course, I'm generalizing control and signal ports. This seems
like a good idea in general, but it may have some drawbacks in
this area... The Standard Range seems to make more sense for
signals than for control data.
//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 : Thu Mar 30 2000 - 13:27:21 EEST