Re: [LAD] Should LV2 Activate() clear MIDI CC parameters?

On Mon, May 28, 2012 at 10:49:06PM -0400, David Robillard wrote:

> > I'd say that the standard case here is to *keep* all the MIDI controller
> > settings, not reset them. Just imagine that you're running a reverb
> > which forgets all settings when you briefly deactivate it in order to
> > listen to the dry signal. That would essentially render such a plugin
> > totally useless. Or am I missing something here?
>
> It does seem like the most reasonable thing to do.

I agree.

This issue raises some other questions on how plugins could/should
handle MIDI input. I offer the following for your consideration and
comments.

The four cases outlined below are in fact points on a continuous
scale, with (1) and (4) being the extremes. The interesting range
is between (2) and (3).

1. The host accepts MIDI input, selects on port, channel, controller
number (e.g. by providing a 'learn' function), and converts selected
messages to control port values. The plugins are never aware that their
input is from MIDI.

2. As above, but the selected data is presented to the plugin either
in MIDI format, or via some more generic 'event delivery' mechanism.
The difference with (1) is that the plugin knows it is dealing with
events.

3. The host provides the MIDI ports, but offers all it gets to any
interested plugin. The plugin performs selection on port, channel
and controller number.

4. The plugin provides its own MIDI input, completely independent
from the host.

Some initial comments:

* One could argue that (3) and (4) lead to a lot of non-trivial
code and development effort being duplicated or repeated for
each plugin. But that need no be the case: the plugin SDK could
offer services that would make this (almost) as easy for the
plugin developer as (1) or (2).

* In (1,2) the selection of port/channel/controller are part of
the host configuration, this data would normally be stored in
the host's session file and the plugins are never aware of it.
In (3,4), the selection criteria become part of the plugin's
configuration, and could be included in e.g. plugin presets.
That makes a difference for the user - but I'm uncertain as
to which would be best.

* I'd expect (1,2) for e.g. individual modular synth modules,
it would feel strange if each individual one would implement
(3,4). OTOH, it wouldn't feel so odd if e.g. a Linuxsampler
or Yoshimi plugin would do that. [*]

* My tentative conclusion would be that a plugin standard
should provide both (2) and (3), and maybe something in
between those.

Comments invited !

[*] Some tricky questions to disturb your sleep:

We now have a few plugins that are in fact complete multitimbral
instruments. Suppose someone would first add LV2 support to AMS
(it can use plugins as if they were native modules), then turn
the complete AMS itself into an LV2 plugin.

- Should AMS then be able to load itself ???
- What impact would that have on the things discussed above ???

Ciao,
 

-- 
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev