8 Feb
2003
8 Feb
'03
1:33 a.m.
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?
2) Do we need a run_adding() form of run()? If so what are the semanitcs
and how to specify the run_adding_gain?
8 Feb
8 Feb
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 ---
2:53 a.m.
2) Do we need
a run_adding() form of run()?
Yes - but we should only encourage it for small/fast plugins that are Is this really worth messing with? This is starting to
sound like
silence handling with plugin granularity...
...
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.
I've never seen such a fast about-face! :) So it is still undecided, then.
Tim
6:54 p.m.
On Saturday 08 February 2003 07.41, Tim Hockin wrote:
> > 2) Do we need a run_adding() form of run()?
[...first "yes" - then "*man*, this is messy!"...]
I've never seen such a fast about-face! :)
*hehe* Well, it's because I keep seeing new parts of the picture. It's
easy when you think about simple FX plugins, but as plugins get
bigger and more complex, things become less obvious.
I'm not saying that run_adding() is useless, but rather that to be of
any use for anything but the simplest cases, it has to be done in a
different way from what we (I?) initally intended. A separate run()
call and a global output gain control won't be of much use in plugins
with lots of outputs.
So it is still undecided, then.
I guess so... I think we should have some optional feature like this,
but I don't think a separate run_adding() will do much good. I used
to think it was only about small/fast plugins, but it's not. It's
about cycles/output.
//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 ---
9:02 a.m.
On Sat, Feb 08, 2003 at 07:16:44 +0100, David Olofson wrote:
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?
I dont think theres much risk of bugs, but the semantics of plugins with
different numbers of inputs and outputs are tricky. Asking the host
authours seems like the best bet.
I know not many people use run_adding in LADSPA.
- Steve
7949
days inactive
7949
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
David Olofson -
Steve Harris -
Tim Hockin