On Sunday 08 December 2002 21.19, Tim Hockin wrote: > > > Well, my first thought is that we don;t want to send a > > > CTRL_CHANGE event to the host every time a control changes, Do > > > we want the host to have to send CTRL_GET events and wait for > > > CTRL_VALUE events, or can we say 'one tick granularity is all > > > the host can get' wrt CTRL_GET? > > > > If the host is marshaling the events then it should know what the > > last controller value it sent to the instrument was. > > I'll buy that. Once the host reads the initial values, it should > refrain from bothering the plugin. > > Aside: Do we see a need for plugins to spontaneously change a > control?
Interesting question... > What of a plugin that has a velocity-capped control (you > turn a knob fast, and it eventually gets there) or something that > crossfades between two values automatically. Sounds like pure implementation details to me. What you do is just say "these controls are *target* values". In fact, most plugins in most APIs do this anyway, since anything else will result in clicking and zipper noise. > Do we need to send > CTRL_CHANGE events to the host, or should we do a 'watcher' > callback. Watchers is how AudioUnits works. I don't really like > it. Sounds like a bad idea to me... You want one callback per sample, or some arbitrary resolution? If you really want a plugin to tell the host (or another plugin) what it's doing internally, publish that through an *Output* Event Port. I don't think there's a good reason to have controls act as both inputs and outputs at the same time, since you can have the exact same functionality with one "target" input control and one "actual value" output control. > Also to think about - what if the host sends a bad value, and a > control wants to reject it? It can't. The host f*cked up, and the plugin may even *crash* without the plugin author deserving as much as a "you might want to fix this" email. > Ahh, asyncronicity. I guess for this > case the plugin sends back some FAIL event or simpler sends back a > CTRL_CHANGE with the old value (or the min/max if the host has gone > too far). Possibly. In fact, that could be a rather nice feature for some stuff. (Say an enumerated integer control, where some values in the middle may not be valid under some circumstances.) Anyway, that would be an *optional* feature. Plugins that just tell the host about the type and range of a control should not be expected to even range check the values they receive. (Why check data stored in the sequencer's data base over and over again, for example? If the host gets data from an untrusted source, check it before it's given to any plugin...) [...] //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 -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---
