Re: [linux-audio-dev] PTAF link and comments

On Thursday 06 February 2003 06.29, Tim Hockin wrote: Then we don't know when to save it, or when to write it back either, I think. Is it state data (delay buffers, filter states etc) or "private" parameter data (FFT spectra, impulses, waveforms etc)? [...default values...] Both alternatives mean code that you have to get right in every plugin. I just don't like the idea of having the same data in two places, or implementing code for stuff that could be done by the host. Some plugin SDK tool to parse metadata and set controls would make me happy, but the latter has only one standard interface (events), which cannot be used without calling run(). Besides, don't forget that setting a control is generally quite a bit more work than just putting the control value somewhere. Some of the Audiality FX plugins call their own control() callbacks to load and *implement* defaults, but that's only doable because FX controls are not (yet) event driven. *How* is it reated to controls? Either it's state information (ie history affected by control and/or audio input) or it *is* control data. There's a big difference in the way you'd use those two things. [...] Then it's *state* data. I don't think mixing that up with non-standard control/parameter data does any good. Like state of a neural network and that kind of stuff? Yeah, then I think I get your point. Each instance of a plugin should be able to remember what it's learned in the environment it's been used. However, I still think this is a form of control data. The only differences are that the plugin will dynamically change the *internal version* of this data (just like plugins that filter control input!), and that it might be of interest to save the internal state, to keep developing it later. 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... If, OTOH, we implement this as two separate controls; one input and one output, this becomes explicit and user controllable. The plugin has an output from which you can read data that represents what the plugin has learned so far. It also has a compatible input where you can write anything you've read from the input, to literally move the plugin back to the state it was in when you read that data. 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. No need for direct reading of inputs. The "internal junk" format controls still have to obey the general rules for controls, or we'll create a real mess. So, there are only two things you can ever find on an input: 1) The default value (whatever put it there...) 2) Some value you wrote there. The obvious question is "What created the value for 2)?" Well, in the normal case, it would be some other plugin (including sequencers and real time input translators), or it's the plugin's custom GUI. Or, it comes from the internal "editor" of the plugin, and is available from an output with the same format. And actual state data, as in "I want it to sound *exactly* as if I started playing a recorded version of the full song from the position this was grabbed", is still something else. *That's* where function calls or some other special interface would make senes to me. It basically involves musical time as an implicit qualifier for the data, and tells the plugin to step aside from normal operation. As such, it does not map to the control paradigm very well. [...] Right - so they shouldn't have a special API either, if we can help it. It just seems hairy and pointless to try to guarantee identical semantics in a different, parallel interface. Agreed. Well, if you're thinking of what I describe above, it's certainly both very interesting and useful. Many VST plugins (like noise reduction plugins) do this - although VST doesn't really support it. It has to be implemented on top of the existing parameter interface one way or another. The only reason it works properly is that VST plugins handle presets themselves, so it's no big deal if some of them do slightly "weird" stuff in this area. Yes - but *when* do you save this data? Since it changes all the time (unless you have an explicit "LEARN" switch control), I'm pretty sure I wouldn't want the host to reread and save it every time I hit "Save" in the host app. Because I was too tired to figure out what I've explained above, about plugins being their own editors. :-) The UI, basically. When to save etc. //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 ---