Subject: Re: [linux-audio-dev] finding the selection length with LADSPA
From: David Olofson (david_AT_gardena.net)
Date: Thu Oct 19 2000 - 10:10:41 EEST
On Thu, 19 Oct 2000, Conrad Parker wrote:
> On Wed, Oct 18, 2000 at 06:25:28PM -0400, douglas irving repetto wrote:
> >
> > it seems to me that an awful lot of filter-type operations are most
> > conveniently handled by a simple "select the region and run the filter"
> > model. and for any process that requires parameters to move from one
> > value to another over the run of the process, the plugin needs to know
> > the total number of samples that have been selected. having a user type
> > in a time parameter could be both awkward and potentially inaccurate.
>
> as most people have pointed out, LADSPA is only designed for dealing
> with audio streams, not segments of a given length. Trying to twist
> the plugins to do anything else is only going to get messy, both for
> you writing the plugin and for the apps needing to coordinate more
> information with the plugin.
If support for this was going to be required from every plugin in
order to do anything useful in an audio editor, yes, this would be
messy, and add lots of tricky code.
However, a plugin that does fades with <start_time, duration> as
input data is not very different from a softsynth, or more
specifically an envelope generator module. The only difference is
that it takes the envelope duration from the "note" event, rather
than as a separate parameter. What's so complicated about that?
(Appart from LADSPA not having an event system to implement it
upon... ;-)
> I'm planning to handle this kind of thing (fades, envelopes) in sweep
> as follows: rather than setting individual numeric parameters, the
> user could provide (draw...) an envelope describing how that parameter
> should vary over the selection.
That's another way of controlling softsynth modules. :-)
> Sweep would then run the LADSPA plugin
> in short sections, each time with slightly different parameter values as
> given by the contour.
That's how you have to do it with VST plugins. (At least the 1.0 ones
- 2.0 does have an event system that *might* be usable for this in
some cases. Would basically mean that you have a specialized plugin,
though, so I don't know if that counts here...)
> This shouldn't be too much trouble from the
> point of view of sweep's LADSPA plugin handler, because it runs
> those plugins in many short sections already anyway.
Hmm... Two problems:
1) Poory written plugins may click, or just consume huge
amounts of CPU power recalculating filter coefficients and
the like. OTOH, those plugins should probably be fixed!
2) No matter what; this method is extremely inefficient...
That said, this method is indeed something I'd like to see! I've been
missing it in the Windows editors. They do run plugins, but they
don't provide usable (if any) means of modulating parameters over
time. (That almost makes the poor excuse for "audio editing" of
Cakewalk a better alternative for the mastering! Only because it has
the usual virtual mixer automation. Scary...)
> In terms of quality, this shouldn't be any worse than the results
> given in a realtime streaming environment (eg. in gdam or quasimodo),
> where the user manipulates a dial to change LADSPA parameter values
> over time.
That's true, and another reason to stick with the claim that plugins
that click or otherwise behave badly, should be fixed.
> The point is that the fading / enveloping ability is managed by the
> host, not by the plugin.
That's actually the Right Thing (TM) to do, but unfortunately, it's
not totally compatible with efficiency... Here comes some of the
strongest arguments for a MuCoS style event system; it makes this
type of control a lot more efficient, as it can be optimized inside
the plugins, there are no extra function calls, and there are no
constant rate control ports that will have to be driven all the time.
Events cost only when they're used, regardless of how many target
parameters the plugin has.
> This is especially important in sweep if
> you've got a selection made up of many discontiguous regions, and a
> parameter envelope that crosses these. LADSPA plugins are invoked once
> for each region of the selection, and it really wouldn't make sense
> for them to have to understand that all this is going on (as they would
> if they had to manage their own parameter fading and other variations).
Sure - but I don't fully understand why plugins would have to bother
with regions in either case. The data from the regions could be
assembled (on the fly) into a homogenous stream *before* it's fed to
the plugin, right?
Alternatively, the host could just cut the regions up into buffers
of suitable size, and utilize the "frames" (samples?) agument. (Or did
that go away? Been doing other stuff for too long...)
> Anyway, I've planned and started speccing out this enveloping stuff
> for sweep, but it's not yet implemented. We can discuss it on
> sweep-devel if you like :) The result would be that a fade could be
> done using the existing LADSPA amplifiers, and filter cutoffs etc.
> could be similarly controlled.
Sounds nice. :-)
> I'm pretty happy with the way LADSPA is defined, it allows plugin
> writers to concentrate on making useful effects without having to
> worry too much about the many ways in which they can be used.
That's a very good point indeed, and that's why I want to emphasize
the importance of looking further than to the problem at hand before
strapping on another API extension. See my previous mail.
//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 : Thu Oct 19 2000 - 11:10:44 EEST