5 Feb
2003
5 Feb
'03
3:28 p.m.
On Wednesday 05 February 2003 19.27, Tim Hockin wrote:
[...]
right, we only need to 'read' data we didn't write.
Actually, do we? Where would that data come from?
IIRC, we concluded that default values should be part of the metadata,
rather than built into the plugin code. Motivation:
* Having plugins load defaults at some point would
violate the semantics of inputs. Inputs should not
change their values spontaneously, but *only* as a
result of incoming CONTROL events.
* Default values must be available to hosts, for
various reasons, so there must be a way to read
them no matter what. If plugins are supposed to
initialize their own inputs, that would mean that
1) they'd all be doing simple stuff that hosts
could handle easilly, and 2) there'd be code that
may have bugs that can take long to be noticed.
So, the host *would* have access to that data, no matter what. If it's
really input data we're talking about, the plugin is not allowed to
modify it, so the default, or whatever we write to the input applies
- just as with any control input.
If it's output data, it's generated by the plugin, and all we can do
is read it. Unless it's "custom" data that some other plugin
understands, in's essentially useless, as we can't write it back.
There *could* be an in/out pair though, so you could feed that data
back into the plugin. That's a separate issue, and I'm not sure what
purpose it would serve, or if it even makes sense at all.
Now, if this doesn't apply at all to the problems that you want to
address with save_extra_state(), please expand. I *suspect* we're
talking about two (or more) different features here.
I don't like that. It seems nasty to prevent people from saving their
work without shutting down the whole engine for a moment. I'm
strongly opposed to the idea of confusing audio time with musical
time, and this is a typical example of assuming they're almost the
same. Stopping the sequencer does *not* mean the audio engine stops.
It *might* in some apps, but that's incompatible with what most users
of "real" synths expect, and should not be enforced.
//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 ---
A generic output is a plugin which wants to emit
control data, but
it doesn't know what it is connected to - might be pitchbend, might
be oscillator shape, might be pan. Generic outputs should emit
normalized data 0.0-1.0. To connect it to anything useful, you
need to scale it by the targets true range.
Ok.
It seems more obvious to me, though, that controls DO
need to do
bounds checking for their inputs, or the host needs to do
snoop-and-fixup for every control.
Yeah, that's basically where I'm getting. I don't really like it,
considering what it does to plugin code, but it's not *that* bad, and
it makes life a lot easier. The cost of having hosts do it would be
*much* higher, and you'd basically have to do it all the time, I
think.
So the way I see saving the state of a plugin:
For each control
save snooped control data to output (maybe XML)
endfor
if (plug->get_extra_state)
d = plug->get_extra_state()
save d as if it were a raw control
endif
Well, that eliminates the need for the in/out pair, which *is* a
special case after all. However, how
do you actually transfer the raw data through that
call? It's just not about a function call, but also about the
data transferred. We'll need an RT safe solution for the
controls. What to do here? Just assume that it's not RT safe?
(Which means you can't save states without taking plugins out of
the net, or requiring that they're thread safe WRT this call...)
I'd assume this is NOT RT safe. Don't save a preset while your
track is running :)