[LV2] should plugins somehow indicate whether they support MPE?

Stefan Westerfeld stefan at space.twc.de
Tue Jun 20 09:11:27 PDT 2017


On Sat, Jun 17, 2017 at 05:39:08PM +0200, Hanspeter Portner wrote:
> On 17.06.2017 13:04, Stefan Westerfeld wrote:
> > I don't know if that affects other plugins (yet), but the next version of
> > SpectMorph will support MPE (Multidimensional Polyphonic Expression). That way
> > a host can change parameters individually of notes that are already playing.
> LV2 parameters/controls for hosts are strict singletons, there is no notion of
> neither polyphony nor per-note parameters/controls.
> But you can of course support that internally in your plugin.

Right. In a way, MPE is all a big workaround for the idea that the host and
plugin communicate notes via MIDI. It allows me to only provide my current
VST2.4 and LV2 plugin, and still get per-note parameters, such as pitch.

I wonder if I should look into supporting VST3, which seems to have this by
design.  But then, LV2, which doesn't have it by design, would also need to be
extended somehow.

> > What I implemented so far in SpectMorph is changing the pitch. Unlike
> > conventional pitch-bend messages, this allows users to bend each note
> > individually. So you could slide from a C major chord to D minor. Obviously in
> > this case, a per-note-pitch UI like Bitwig provides - which I used for
> > developing and testing - makes sense.
> How do you plan to implement the MPE controller messages (e.g. pressure/timbre
> in MPE terms). Would you take the current singleton lv2:Control/Parameter value
> as initial value for each new note and overwrite it accordingly to MPE
> controller messages? What if the initial parent lv2:Control/Parameter is changed
> by the host simultaneously? Just curious.

To be honest, I don't know yet how per-note timbre events should be handled. It
is probably not as simple as you say, because often we have internal LFOs in the
plugin which affect timbre. This is because (unlike Bitwig), most hosts - as far
as I know - do not allow you to say: this timbre parameter should by default
vary with a sine wave with 0.2 Hz.

So just taking the LV2 control parameter for timbre is often not good enough,
the user can already make this parameter vary according to an LFO.

It could work like: use either
 - internal LFO
 - LV2 control parameter

if no other information is there, and use MPE timbre directly otherwise. This
would mean that the MPE timbre overrides any other (default) specification
for timbre.

> > In VST, my plugin reacts to a new canDo("MPE"), to indicate to hosts with MPE
> > support that MPE messages should be sent (like per-note pitch bend). Bitwig for
> > instance will not send any MPE messages to the plugin unless this canDo is
> > supported.
> > 
> > Since MPE is midi-only, my LV2 plugin will automatically support MPE now.  I
> > wonder if it should somehow in the plugin description indicate that it does.
> Suport could be annotated on the port with an atom:suppports property.
> mybundle:myplug
>   a lv2:Plugin ;
>   lv2:port [
>     a lv2:InputPort, atom:AtomPort ;
>     lv2:index 0 ;
>     lv2:symbol "myPort" ;
>     atom:bufferType atom:Sequence ;
>     atom:supports midi:MidiEvent, midi:MpeMessage ;
>   ] .
> And midi.ttl be extended with a definition of midi:MpeMessage
> midi:MpeMessage
>   a rdfs:Class ;
>   rdfs:subClassOf midi:MidiEvent ;
>   rdfs:label "Multidimensional Polyphonic Expression" .

Sounds reasonable.

> > I don't know any LV2 host that supports MPE so far, so if the LV2 strategy for
> > MPE would be wait until we have at least one host which supports MPE, and then
> > discuss negotiation, that would be ok for me, too
> Or better: wait until the MPE spec actually is finalized. Currently the draft is
> under (closed) consideration by the MIDI association, iirc, and it may well
> change. Once something is in the LV2 spec, it cannot (easily) be changed...

Ok. So we can wait for that to happen before annotating it.

> I'm pretty interested in polyphonic expression, but the MPE draft is terribly
> broken, as it only allows 15!!! concurrent notes at max.

MPE is a workaround. The proper way to do it would be somehow like VST3, where
the host tags (as far as I understand it) each note on event with a unique id.

That way, subsequent note expression parameter changes go to a note id. Since this
is not limited to 15 ids, we can avoid the problem you mentioned.

But this would mean that LV2 somehow would need to have
 - a protocol (other than midi) to send note on events, so that a note id can be
   assigned by the host
 - a way to send per-note expression control changes
 - a way to define per-note controls

If LV2 had this, I could probably support it, and hosts that supported it would
simply work with LV2s per-note-expression protocol. Also standard parameters
like per-note-pitch should be defined, and would then only affect the note with
the right id.

   Cu... Stefan
Stefan Westerfeld, http://space.twc.de/~stefan

More information about the Devel mailing list