8 Feb
2003
8 Feb
'03
2:49 a.m.
On Saturday 08 February 2003 06.51, Tim Hockin wrote:
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.
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 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 ---