[linux-audio-dev] Re: David, please explain you thoughts about Levels

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

Subject: [linux-audio-dev] Re: David, please explain you thoughts about Levels
From: David Olofson (david_AT_gardena.net)
Date: Fri Mar 17 2000 - 17:42:43 EST


On Thu, 16 Mar 2000, Benno Senoner wrote:
> David,
> please write to Richard, CCing the linux-audio-dev please,
> which is in your opinion, the best way to implement levels into plugins.
>
> Under levels (if I am not missin something), we understand a way
> for the host telling the output level (volume,gain) to the plugin,
> so that the plugin itself can mix at the host's desired volume.
>
> This method is particularly useful when we use the processAdd() method,
> since the plugin directly adds the samples to the buffer,
> therefore the host has no way to control output volume,
> except running in processReplace() mode and doing gain processing
> in the host code, but that would slow down things quite a bit, since you
> have to give up the processAdd() method on every plugin where you want
> to control the output volume.

Exactly, and that, as far as I can see, is the case with every
insert fx that send to the busses on a virtual mixer. There are level
controls everywhere, and most of them will have a plugin just behind
them in the chain. With a standardized way for the host to access the
output gain controls (available in many VST and DirectX plugins,
although they're next to useless in a host with a virtual mixer...),
these level controls don't have to be implemented as extra plugins,
or host inlines, both of which render the process_mix() method
useless.

> I think from a technical point of view it is not that hard to implement,
> just include a setOutLevel() , and getOutLevel() callback, and
> then simply let the plugin use this variable to multiply the output samples
> before adding the results to the outbuffer.

Something like that.

(BTW, that's the VST way of implementing it, and I just think it adds
weight without any real life advantage. I'd use the LADSPA control
ports instead, as they're the standard way of controlling those
plugins. MuCoS would use events, of course.)

Anyway, the point is, this means no change in the plugin code. The
only change is that there is a way to locate certain controls and use
them in a standard way. It's just about recommending that developers
use linear level controls with a 0 dB level at 1.0 (or whatever we
agree upon), rather than countless different variants. That is,
making control ports more generic, which is a good idea anyway, as
it also means less confusion for users. (Note: This does not in any
way mean that it should be hard or impossible to use control ports
not defined in the standard. Using the standard mapping is optional -
plugins will still work in any host even if you ignore it.)

//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 -'


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

This archive was generated by hypermail 2b28 : Sat Mar 18 2000 - 07:31:22 EST