10 Dec
2002
10 Dec
'02
3:05 p.m.
On Tuesday 10 December 2002 08.00, Tim Hockin wrote:
Yes, but requiring that would mean you have to rewrite all controls
whenever you change one of them, even for automation.
Yeah, but that turned out to be the easy part... The interface may
look simple, but it implies quite a bit of hairy situations.
In short, not worth the effort, especially considering that it's just
an emergency exit for bad plugin designs.
//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 -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
It doesn't
have to, unless it actually cares. If you save a
preset with a "bad" value in some field, the plugin will just fix
it when you load the preset.
There's just one problem: In what order do you write the controls
back to ensure you end up with the exact same result?
The order the plugin presents them to you? If there are
dependencies between controls can we have the plugin author be
responsible for making their indices reflect it? Otherwise we can
add yet another field to controls which says the order in which to
write presets. Ick. Serialize/deserialize solves this nicely, btw
:)
Aaargh! Nooo!!! :-)
Anyway, I think this issue has been resolved rather nicely already.
We concluded that if a plugin for some reason does not want to
"accept" certain values, it has to deal with that internally, in a
concistent way which depends only on the current values of controls
involved.
It's real simple actually; just have a single function
fix_bad_values() that you call whenever one of the interdependent
controls changes. Then it doesn't matter in which order you write the
controls; the function will always do the same thing.
Oh, and it seems that this applies to 1 plugin in 100 or so - and
that one is probably just a poor design in the first place. :-)
Anyway, if the
host *does* keep track of "last value written",
supporting the "I'll make that X instead!" event is just a matter
of writing X into that "last value written" variable.
Exactly. If a plug doesn't support it, no big deal. If it does,
cool.