5 Feb
2003
5 Feb
'03
9:47 p.m.
On Wednesday 05 February 2003 23.57, Tim Hockin wrote:
Internal.
Yes - but it has to come from somewhere, and it has to make sense to
write it back.
Sounds like plugin state data to me, but other parts of this
discussion suggest that it's for *parameter* data that won't fit in
standard control datatypes. These are two rather different things.
Random garbage or zeroed?
*I'm* not sure about *anything*... ;-)
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.
I don't know - if the metadata lists the default, do we really need
to write that value to it, or can we assume that when you create
the plugin the controls have their default values. They have to
have SOME value. Might as well be defaults.
But then someone actually has to hack the code to put the right value
in the right place - and get it right. Why do that *and* put the
values in the metadata? I see redundant code, as well an easy way of
creating strange bugs.
The only point I can see in having plugins doing it is that it would
be a bit faster, which matters if you want to do real time
instantiation.
I was thinking that you could provide a plugin SDK function that
parses metadata and loads defaults through the control interface -
but then I realized it's kind of nasty (if at all possible) to have
plugins call their own run() callbacks from the wrong context. *heh*
How about allowing lazy plugins to ask the host to load their defaults
for them?
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 am not sure what you're talking about anymore :) I'm suggesting that with a document
(song/track/whatever) a plugin
may want to save some state that is NOT control data. The only
examples I can think of right now are things like fftw wisdom or
maybe tables for a wave-table synth with custom waveforms. In fact
that is a good one.
This sounds like a form of control data to me. It's stuff that you
can't get back in there in any other way than explicitly writing it
back.
That is, it's *not* state data. State data can (at least
theoretically) be reconstructed by creating a new instance and
feeding the control and audio inputs with the exact same data as the
original got.
I think it's a very big difference. I also dislike the idea of
treating *some* control data in completely different ways.
It is somewhat related to a control, but it is not
input or output.
Parameters. Most plugin APIs have both parameters and controls, but I
see nothing but poorly motivated redundancy.
We have discussed presets and basically concluded that a preset is
nothing but a full set of control input values. This is where most
plugin APIs use an alternative API instead - and as a result, you end
up having to think carefully about what you want to make controllable
in real time, and what you want to be able to save in presets. You
*can* usually automate the parameters as well, but that's has to be
handled specially by the host - and of course, it will generally not
be sample accurate or support ramping. This all looks pointless,
messy and restrictive to me.
We have controls for everything, and that's really rather handy in
many ways. Let's not ruin that design.
Now, *state* data is another thing. It has nothing to do with "opaque
control types" though, so that would be a *third* interface, provided
we have a special one for raw data block controls.
It is internally generated and can safely be cached
until the
waveform changes.
The host never reads or writes that data, but the plugin would like
to save that data with the document or preset.
plug->get_extra_state() hands back a raw-data block. We can base64
it and store it in our XML preset file, or whatever we want. When
we reload a document, plug->set_extra_state() gets the raw_data
block back, if we have one.
Yes, I see. But I still don't see how you wold *create* that data in
the first place, unless there is an interface that a GUI plugin or
similar can use to access it. If what you mention here is all there
is to it, there's no reason to store the data, because it will have
to be hardcoded into the plugin anyway.
Am I clearer with a real example?
Maybe. It seems to me that the *_extra_state() calls are just half a
solution, since they can only be used to save and load data that
cannot be edited. I must be missign something.
[...]
ok, so perhaps we can say that it falls under some RT
constraints.
A plugin which has extra state has an RT problem. If you want to
call the extra_state functions you need to do it in a separate
thread (thus mandating thread safety - ugg) or you need to remove
it from the net.
Another way is to stream the data, block by block... *hehe*
//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 ---