Re: [linux-audio-dev] Levels, Instantiate, Extensions/Finalisation

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Levels, Instantiate, Extensions/Finalisation
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Mar 16 2000 - 07:38:58 EST


On Thu, 16 Mar 2000, Richard W.E. Furse wrote:
>
> As far as I can see, the description above and thus (hopefully!) LADSPA
> just says 'something that processes audio' and I'm not sure that levels
> really come into it - unless perhaps we consider the level of descriptive
> information provided. The self description part has become vastly extended
> but the heart of the API remains the same.

I vote for including levels, since it will add a bit more flexibility when it
comes to mixing issue.

>> As far as I can see SC should be fine instantiating appropriate plugins at
> runtime but IMHO instant initialisation is not practical in general and
> should not be mandatory. My vote, as I think I posted before, is that SC do
> timing tests, perhaps offline in a separate program, to establish what
> plugins instantiate are fast enough for use live.

fully agree,
these timing tests, should be made considering the actual
num of samples which are processed in each loop.
That means the shorter the loop (fragmentsize, thus latency)
the faster the init function has to return.
(using 200ms fragments, allows you to call init routines which take
quite long ,( you can zero out quite a bit of mem in this time :-) )

>
> (1) I can see the arguments in favour of some kind of initialise()/finish()
> functions on plugins. They are hooks that can be mostly ignored by the
> plugin developer and are rather useful at times. They are a little hassle
> for the host but not much if the host just calls them along with
> initialise() and cleanup() - and they do have some interesting implications
> for device access etc on more careful hosts.

Agree here, I am for the initialise() , finish() functions, which should
be the "prepare" stage for the plugin,
EMAIGCs EASI plugin standard uses this, and on some devices/algorithms
this could be quite handy.
If a plugin doesn't need this feature, just leave the functions empty.

>
> (2) Yes yes yes I've not been completely ignoring you all ;) An optional
> runAdd() method could be useful too as a specialised performance
> optimisation. Plugin writers don't include these if they don't want to and
> hosts can ignore them.

can ignore ... but for performance reasons he should implement this method
since plugins comes very often in chains, and there is where you get the
speed advantage due to cache reusage etc.

>
> My only real objection is that these add flab (size, complexity, potential
> confusion) to the API. I be convinced on both counts if enough people are
> interested. Sounds like you probably are on runAdd() - I hope you're not
> just copying VST though... (Finally had a chance to look at the SDK last
> weekend.)

One of our goal as mentioned before, should be to allow a VST1-compatible
framework (LADSPA should be able to do all what VST1 does),
so that a VST->LADSPA wrapper becomes easy to write.
And that winwos-plugin writer can begin to test their plugins on Linux
without requiring them to rewrite everything.

Any objections to my thoughts ?

Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Mar 16 2000 - 14:27:19 EST