[ arguing get/set_extra_state()...] > Oh wait, there's one more difference. If we just assume that this is > data that the plugin wants to store whenever you save a project, we > have major issue: A project will *change* in non-obvious ways if you > repeatedly play and save, without explicitly editing anything. That > sounds very scary to me...
urr, yeah. That is a good point. I'm willing to drop this one for now. Let's go about our business and see if it ever is needed. at which point we'll know a lot more about the problem. My original thought was that we couls use it as a way to save time when reloading a plugin. Stuff like wave-table data that is calculated from a waveform once. We can always recalculate it, I guess. > As an example, if you have a compressor that can adjust to how you > sing and handle a mike, just hook it up and sing some, to "program" > it. Then grab the state output data and save it in your preset, as > the "value" for the corresponding input. Whenever you load that > preset, the plugin will behave exactly like you trained it to. (Or > rather, the way it *thinks* you want it to. ;-) > > In short, we're talking about DSP plugins that are also their own > parameter editors, using live input in non-obvious ways to do the > editing. > > Sounds like a *very* interesting concept to me, and I definitely think > we should try to get the supporting interfaces right. This is vaguely interesting - dunno if there is a real need for it, or if existing interfaces need mods at all. 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.