Subject: RE: [linux-audio-dev] finding the selection length with LADSPA
From: David Olofson (david_AT_gardena.net)
Date: Mon Oct 23 2000 - 02:54:11 EEST
On Thu, 19 Oct 2000, Richard W.E. Furse wrote:
> Ooo a fun subject. A tightly related issue is whether or not the plugin is
> allowed to exhibit non-causal behaviour. Should a plugin be able to see
> into the future? And see which bits of information? As LADSPA plugins are
> supposed to be able to run against live streams, the answer is no. OK, some
> plugins could support extra functionality that cuts in only when running
> offline, but...
I don't think this destinction is required for most of the things
that may seem to point in that direction. How about "carrying out
orders addressing the future" rather than "knowing about the
future"...? That is, plugins still know nothing about the future;
they just have the capability to understand commands with a duration
argument.
> Just as fuel for thought, consider how best to encapsulate a 'reverse'
> plugin. The plugin needs its last input sample before it can produce any
> output. It needs to know how long it is to run and all data that will ever
> be fed to it. An API supporting this isn't hard to build, and a natural one
> gives the plugin something that looks like a random-access file system. But
> it cannot be run 'live' in any meaningful sense and is a fundamentally
> different signal-processing paradigm to the somewhat narrower one LADSPA
> addresses.
If the random-access style API interfaces to locked RAM data, it
could be done in real time, and it's actually a rather interesting
and useful feature.
But in the context of the LAD*S*PA API, I think this is better done
by the host, possibly using plugins under some other plugin API,
which would obviously have to be quite messy and incomprehensible
compared to LADSPA. LADSPA plugins would still work well i the same
environment, doing the signal processing, as everything will
eventually have to conform to something very similar to the concept
that LADSPA is designed around.
> I like the sound of Conrad's future graphical implementation of control
> manipulation - I'll be playing with this when it comes out!
>
> In response to David's related mail, running plugins in short sections and
> then changing parameters is explicitly supported by the API - properly
> written plugins (and anything in CMT) will run quite happily. As you point
> out, poorly written plugins should be fixed.
<useful tool idea>
BTW, I found some interesting code that I might turn into a handy
tool for generating fast filter coefficient approximation code and
that kind of stuff. The idea is basically to approximate any function
(trig, n-th grade polynomials etc) with simpler functions that are
better suited for audio plugins.
In general, a perfectly accurate and correct formula will only waste
you CPU time without generating an audible improvement, so why not
just type it in along with the accuracy you need, and then recieve a
polynomial function, an interpolated LUT or something?
I have working C code that generates N-th grade polynomials from
tables on the form <input, output>, and I have a half-finished
formula parser written in yacc and C lying around somewhere... Glade
is fun to play with as well, if a GUI is needed, but I'm not sure
there's much point in anything but basic graph plotting - something
that there are plenty of existing packages for.
Sounds useful? Ideas?
(I know you can do the maths behind this with serious math packages,
but you have to be rather serious about maths to figure out how to use
them... This would be a small and rather specialized tool for
optimizing code otn the algo + maths level, for people without a
higher grade in maths.)
</useful tool idea>
> On the efficiency side, this memory reference approach is the most
> efficient system I'm aware of under most (all?) circumstances where an
> unpredictable agent is feeding scalar control information to the plugin
> (okay, things are less simple for complex event data). If the plugin has a
> high control-rate overhead because of filter coefficient recalculation or
> suchlike it can simply cache its last calculations - the implicit overhead
> is then just an if call. [In this context the issue of whether or not the
> plugin is entitled to call itself 'hard' realtime is more subtle...]
As long as it can guarantee that a run() call will never take more
than a certain factor times the average execution time, it should
work. (If you're looking for a theoretically perfect approach with
"Nuclear Plant Control Class" reliability, you'd better write all you
DSP code yourself, according to the rules of the particular design,
rather than trying to run audio plugins... Statistics of hours of
benchmarking is the best we can do with realistic efforts.)
//David
.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Mon Oct 23 2000 - 04:04:43 EEST