[LAD] Should LV2 Activate() clear MIDI CC parameters?
d at drobilla.net
Mon May 28 17:27:46 UTC 2012
On Mon, 2012-05-28 at 18:41 +0300, Stefano D'Angelo wrote:
> 2012/5/25 Jeremy Salwen <jeremysalwen at gmail.com>:
> > Hi all,
> > The LV2 spec says that on a call to activate(), "the plugin instance MUST
> > reset all state information dependent on the history of the plugin instance
> > except for any data locations provided by connect_port()"
> > I am not certain whether MIDI CC parameters are included in this category of
> > "data locations provided by connect_port()". The CC parameters are sent
> > through port buffers provided by connect_port(), but because they are event
> > buffers, all information passed through them is necessarily part of the
> > history of the plugin instance.
> > I could imagine cases where you would want to reset all internal state of
> > the plugin, but since CC values are very much like port values, they would
> > be kept. On the other hand, I could also imagine cases where you would want
> > to reset all internal data including the CC parameters.
> > I'm assuming MIDI note on/off status certainly should be reset.
> <personal opinion>
> I have always interpreted activate()/deactivate() as a real-time safe
> alternative to instantiate()/cleanup(), so I'd say restart fresh, wipe
> out everything.
> I do not necessarily agree that MIDI CC is like a port value, since
> when the first run() after the first activate() is called and there's
> no incoming CC event, however you probably need to be in a certain
> "initial state".
> </personal opinion>
The spec explicitly states: "the plugin instance MUST reset all state
information dependent on the history of the plugin instance except for
any data locations provided by connect_port()"
This text does date from a time when that was the only way to actually
get any data in/out of a plugin, so it might need clarification now with
For live plugins if you're going to stop continually running the plugin,
you must deactivate it, so I can see how a complete and total state
reset here might be undesirable. I'm not sure. A complete
cleanup/re-initialization is always an option for a total reset, though
of course not real-time whatsoever.
> Concrete use case would help.
More information about the Linux-audio-dev