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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
