[LAD] How can a LV2 plugin know on what host's MIDI Channel it's on?

[David Robillard]

On 2014-11-15 04:56, Rui Nuno Capela wrote:
> On 11/15/2014 05:55 AM, David Robillard wrote:
>> On 2014-10-16 11:42, Phil CM wrote:
>>> Is there a way to retrieve this info (and others, ideally) from the
>>> host, thus removing the need for a "midi channel" control port?
>>
>> It would be simple for the host to send a message describing this or
>> whatever other information, but I don't really see the point.
>>
> 
> qtractor ensures that the plugin only receives MIDI messages that are
> "stamped" with the proper MIDI track assigned channel.
> 
> otoh. i guess the so called "MIDI channels control port" may only make
> sense to stand-alone cases or for plugin instances that may act like so
> (eg. when using jalv).

Since the host would have to support such a thing anyway, it might as
well just support MIDI channel filtering/assignment/etc itself.  No
sense adding a bunch of LV2-specific work for everyone when nothing else
works that way.

It's not technologically a big deal to add such a thing (purely
metadata, no API needed), but I don't see anybody actually using it.
Given the choice, pushing complexity into the plugins is a bad idea anyway.

>> ... the fader in a DAW typically does its own thing with the signal at
>> that point, and wouldn't be mapped to a plugin volume anyway.  Since
>> there can be many plugins in a strip, this doesn't really make sense.
>>
>> It sounds like your plugins are post-fader, which is not what you want,
>> but I don't know Qtractor.
>>
> 
> the faders in qtractor MIDI tracks/buses strips are indeed special MIDI
> controls. eg. for MIDI tracks the volume fader/slider is tied to MIDI
> CC#7 (GM channel volume). these MIDI channel messages are indeed sent
> through the MIDI plugin chain. nb. that in qtractor you can have more
> than just one MIDI intrument plugin inserted in a MIDI track/bus.
> 
> in this MIDI control model, *it is* the plugin's resposability to comply
> with the GM spec (or not), either by implementation or its own
> configuration option. like it has been for all external or stand-alone
> MIDI equipment be that soft- or hard-synths, etc.
> 
> remember, plugins aren't the only form of MIDI instruments thatat exist,
> and qtractor still is a *sequencer* designed to drive all other forms.
> 
> also, in this sense, all MIDI strip plugin chains are regarded as if
> it's "pre-fader" if one looks at it as in the audio signal sense, but
> let me refrain that it is dealing with MIDI control flow and *not* with
> the audio one, so calling it pre- or post-fader isn't actually
> applicable to MIDI tracks/buses.

Ah, MIDI only (I was thinking instruments => audio at fader point).
Seems an odd choice to not have an audio fader on a track with
instruments though, if I understand the situation correctly.  You won't
be able to control the overall volume sometimes...

Anyway, that's a Qtractor thing.  With respect to plugins, I agree just
acting like any other MIDI box is the correct thing to do, unless
there's a good reason otherwise, which I don't see here.

A designated volume port would allow hosts to control plugins similarly
*not* via MIDI, wherever that's useful.  We currently have a gain
designation, but no volume.  I guess "volume" would be normalized
0=silence 1=no attenuation.

-- 
dr


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20141115/78794b45/attachment.pgp>