8 Feb
2003
8 Feb
'03
2:24 a.m.
On Saturday 08 February 2003 06.21, Tim Hockin wrote:
Items we haven't agreed to a solution on (or that
I missed the
solution for :)
1) Do plugins load the default value for all their controls or do
we have to send an event for data they already know?
There is one rather strong motivation for using control events:
There's often a lot more to setting a control than just putting the
value somewhere. Setting a control often means you calculate some
filter coefficients, reallocate buffers or whatnot. (*)
That is, even if there was a nice and clean way to parse the metadata
and write the defaults directly into the internal control variables,
it wouldn't really work. It's about *real code* getting duplicated
inside plugins; not just values being moved around.
(*) And here's a nice trick you can do with worker callbacks!
When instantiating and loading defaults, just do it under
a host struct that implements worker callbacks by calling
them directly. Plugins that normally use this mechanism
to perform RT safe async reallocations will Just Work -
just as they would in an off-line host.
2) Do we need a run_adding() form of run()?
Yes - but we should only encourage it for small/fast plugins that are
expected to be used in many instances, and/or commonly used as the
last stage in mixer strips and the like.
Maybe we should even *discourage* authors of plugins with high
cycles/output ratios from implementing run_adding(), to reduce the
risk of bugs?
Also, there's a major issue with run_adding() and plugins with many
outputs: It's either or. Either all outputs overwrite, or all outputs
add. Deciding when to use run() or run_adding() is non-trivial and
h/w dependent, since it depends on the cost of clearing output
buffers vs mixing with extra buffers.
Is this really worth messing with? This is starting to sound like
silence handling with plugin granularity...
If so what are the
semanitcs and how to specify the run_adding_gain?
Well, there's another issue. For this to be truly useful, the gain
would have to be a ramped control, and there would have to be one for
each audio output. Simpler versions *could* be useful, but I have a
feeling that it would only cover some special cases, rather than your
average automated mixer session.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---