Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Sat Feb 08 2003 - 08:41:43 EET
On Saturday 08 February 2003 06.51, Tim Hockin wrote:
> > > Flip on the LEARN control, do your stuff. When you flip off
> > > the LEARN control a raw-data output is updated. We don't even
> > > need to use a hint for LEARN - it is totally plugin unique.
> >
> > Right. As long as there is suitable control datatypes, no
> > additional support is needed, really. It works without explicit
> > support.
> >
> > That said, it might be nice to allow plugins to somehow hint that
> > an output generates data that you may write back to a specified
> > input of the same type. This would allow hosts to be smart about
> > this, rather than just showing these controls as normal, totally
> > unrelated inputs
>
> Using an output control for this is actually wrong, on another
> thought. You would NEVER save a VOICE output control or anything
> else output with a preset. Output goes to some other place.
That's exactly why it *should* be an output. If it was a "readable
input", it would be saved with the preset whether you like it or not,
and there's that problem with mysteriously mutating projects again.
> Just because we CAN get data out of an output control, doesn't make
> it consistent with the semantics of an output control.
It *could* still be, but as always, really, it's for the plugin to
decide when it wants to update the value on an output. The only
strict rule is that any output has to send it's current value
directly after a connection is made. Some outputs might do *only*
that, although it would actually make a lot of sense if these ones
would update whenever you flip that "LEARN" switch.
So, you *could* have them connected at all times, and they would still
work as expected.
As a matter of fact, if you just loop the output back to the input,
the "LEARN" switch is all you need. Whenever you flip the switch to
"off" the new data would be send back to the input. When you save a
preset, the host would see the connection of the input and go look
for the current value - which it finds on that output.
Just make that loop and it all Just Works(TM). Cool, eh? :-)
If the plugin doesn't have a LEARN switch, it gets less sexy, but that
could be done as well. If you have a user tool that can grab a value
from an output and put it on an input, you'll be fine. You could
easily do things like taking the "knowledge" output from a plugin in
a dummy training net and writing it directly to the instance in the
real net.
> We'd need Yet Another Flag that says a control is an output that is
> meant JUST for preset data.
>
> Ick?
Well, it should probably be hinted "don't make me a wire in a cable,
please!", so hosts with that kind of connection features don't mess
up when you chain these plugins. (You probably don't want to chain
those unless you're looking for truly weird effects... Plugins
learning from each other? :-)
//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 ---
This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 08:40:07 EET