Re: [linux-audio-dev] changing control port values with LADSPA: a serious issue?

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

Subject: Re: [linux-audio-dev] changing control port values with LADSPA: a serious issue?
From: Stefan Kost (kost_AT_imn.htwk-leipzig.de)
Date: Wed Apr 03 2002 - 12:22:04 EEST


I though further about the problem with changing parameter values. So what I would like to know is what SampleCount
values are authors of plugin-host are typically using ?
E.g. SampleCount of 256 at 44100 hz would mean about 6ms between each parameter change. If we are using values low
as this then the host could care about delivering smoth data.
I currently evaluate LADSPA to be the format for the plugins I rewrite from my software SoundFX and there most
parameters are specified by a lowerand a upper bound + a modulation function which is called at a lower frequency
as the audio-generating code. The modulation function always returns values between 0.0 and 1.0 which gets turned
into an alteration of the parameter between lower and upper bound. There are modulation functions such as LFO's,
Fades, Envelopes, Sample&Hold, Envelop-Trackers (Pitch and Volume) and many more. I am now thnking at which level
to integrate those : plugin-host level integration would be easier.

Additionally I would suggest for LADSPA V2
that we have
   #define LADSPA_PORT_CONTROL_STATIC 0x10
which means that the parameter needs only to be evaluated in the
   connect_port(LADSPA_Handle Instance,unsigned long Port,LADSPA_Data * DataLocation)
method and that the host *must* call this method when such a parameter has changed. This could e.g. used for parameters such as
fft-size, filter-type, note (of a synth plugin such as 'C-3') which are unlikely to change often and probably need several initial
calculations before further processing could be done. Such parameters would never be interpolated !

Stefan

> On Mon, Mar 25, 2002 at 02:09:20 +0100, Stefan Kost wrote:
>
>>Additionally it introduces processing overhead, as parameters usually don't change that much.
>
>
> Agreed, there are definatly some parameters that can't/shouldn't be
> interpolated.
>
>>Ideas :
>>1.) What about if the host takes care about avoiding cracks due to parameter changes. Right after a parameter change,
>>it could call the plugin twice and then x-fade the outputs.
>
>
> Not all plugins can be xfaded to produce meaningful results, not to
> mention it doubles the cpu use, and you need two instances of the plugin,
> with the same state.
>
> The host can't reasonably do the parameter edge filtering, as it doesn't
> know what the appropriate scheme is. Sure, you could code up all the
> common schemes (and thier parameters) and express them as port metadata,
> but that seems uneccesarily complicated.
>
> - Steve
>

-- 
       \|/
      <@ @> Stefan Kost  private                   business
+-oOO-(_)-OOo------------------------------------------------------------- - - -  -   -
|        __    Address  Zwenkauer Str. 24         HTWK Leipzig, Fb IMN, Postfach 300066
|       ///             04277 Leipzig             04277 Leipzig
|  __  ///              Germany                   Germany
|  \\\///      Phone    +49341 3910483            +49341 30766101
|   \__/       EMail    st_kost_AT_gmx.net           kost_AT_imn.htwk-leipzig.de
|              WWW      http://www.sonicpulse.de  http://www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -


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

This archive was generated by hypermail 2b28 : Wed Apr 03 2002 - 12:13:12 EEST