6 Feb
2003
6 Feb
'03
1:40 a.m.
right, we only
need to 'read' data we didn't write.
Actually, do we? Where would that data come from? 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. How about allowing lazy plugins to ask the host to
load their defaults
for them?
It won't hurt for a plugin and host to BOTH do it. I just think that
defaults should be set by the plugin. It doesn't cost anything beyond init
time, and just seems RIGHT.
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. I think it's a very big difference. I also dislike
the idea of
treating *some* control data in completely different ways.
Parameters. Most plugin APIs have both parameters and
controls, but I
see nothing but poorly motivated redundancy.
I don't want non-control controls. Controls are controls. And we have a
way of knowing their data. What I am saying is that there might be some
state that the plugin wants to save with a preset that is NOT user
controllable and is not a control.
We have discussed presets and basically concluded that
a preset is
nothing but a full set of control input values. This is where most
Right. Except what of a plugin that wants to store <something else> with
the preset. This is stuff that it has generated and wants to come back with
the preset.
We have controls for everything, and that's really
rather handy in
many ways. Let's not ruin that design.
OK, then we need a way to read controls, directly. Then the plugin can just
use a raw control for it's internal junk.
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.
I don't think raw data controls are special in any way...
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 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.
That is correct - they just save some chunk of crap that the plugin wants to
know when you reload it. Why is that half the solution? What other half of
the problem exists?
Tim