16 Oct
2014
16 Oct
'14
5:42 p.m.
Is there a way to retrieve this info (and others, ideally) from the
host, thus removing the need for a "midi channel" control port?
Also, is there a way to tie the "volume" controller of the host (in
Qtractor's case, the volume fader of the mixer strip) to one "volume"
control port of the plugin, thus removing the need for the "control
mode" control port ?
Yes because you see, here in my Qtractor (latest SVN - but it has always
been that way) I can either edit the plugin (about 50% of my plugins
behave that way) controls but then the mixer's volume is inoperant, or
control the volume w/ said mixer but NOT the plugins controls. How can I
have my cake and eat it?
Ta-ta
--Phil
16 Oct
16 Oct
6:15 p.m.
New subject: How can a LV2 plugin know on what host's MIDI Channel it's on?
On Thu, Oct 16, 2014 at 11:42 AM, Phil CM <philcm(a)gnu.org> 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?
I think you're confused. The host doesn't put a plugin on a MIDI channel.
It delivers MIDI events to the plugin which might be on any channel.
Also, is there a way to tie the "volume" controller of the host (in
Qtractor's case, the volume fader of the mixer strip) to one "volume"
control port of the plugin, thus removing the need for the "control mode"
control port ?
Absolutely not. Except via an extension to LV2 which both the host and
plugin would have to support.
8:03 p.m.
New subject: How can a LV2 plugin know on what host's MIDI Channel it's on?
Here's a vote for anything (lv2 extension, OSC convention, or something else) that
makes information about how a host is using a plugin available to the plugin.
This kind of introspection is useless for most plugins, but those that need it can't
get the information any other way.
In MFP [1] I have support for a loading an editable patch as an LV2 plugin. It would be
really useful to be able to find out from the host what channel each instance is on, both
for presentation in UI and for support of automation-type behavior where the plugin might
automate usage of (for example) a hosts OSC API, using its channel number to parameterize
the OSC call properly. This is what I think of as the "max4live" workflow.
Thanks,
Bill Gribble
[1] http://github.com/bgribble/mfp
On Oct 16, 2014, at 11:42, Phil CM
<philcm(a)gnu.org> 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?
Also, is there a way to tie the "volume" controller of the host (in
Qtractor's case, the volume fader of the mixer strip) to one "volume"
control port of the plugin, thus removing the need for the "control mode"
control port ?
Yes because you see, here in my Qtractor (latest SVN - but it has always been that way) I
can either edit the plugin (about 50% of my plugins behave that way) controls but then the
mixer's volume is inoperant, or control the volume w/ said mixer but NOT the plugins
controls. How can I have my cake and eat it?
Ta-ta
--Phil
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
8:21 p.m.
On 16/10/14 19:02, Bill Gribble wrote:
Here's a vote for anything (lv2 extension, OSC
convention, or something else) that makes information about how a host is using a plugin
available to the plugin.
This kind of introspection is useless for most plugins, but those that need it can't
get the information any other way.
Indeed, "most plugins" seem to get this
in information as to what track
they are in (Calf MonoSynth, randomly) so how do I implement that in "my
plugin"? :)
pX
In MFP [1] I have support for a loading an editable patch as an LV2 plugin. It would be
really useful to be able to find out from the host what channel each instance is on, both
for presentation in UI and for support of automation-type behavior where the plugin might
automate usage of (for example) a hosts OSC API, using its channel number to parameterize
the OSC call properly. This is what I think of as the "max4live" workflow.
Thanks,
Bill Gribble
[1] http://github.com/bgribble/mfp
On Oct 16, 2014, at 11:42, Phil CM
<philcm(a)gnu.org> 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?
Also, is there a way to tie the "volume" controller of the host (in
Qtractor's case, the volume fader of the mixer strip) to one "volume"
control port of the plugin, thus removing the need for the "control mode"
control port ?
Yes because you see, here in my Qtractor (latest SVN - but it has always been that way) I
can either edit the plugin (about 50% of my plugins behave that way) controls but then the
mixer's volume is inoperant, or control the volume w/ said mixer but NOT the plugins
controls. How can I have my cake and eat it?
Ta-ta
--Phil
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
9:40 p.m.
New subject: How can a LV2 plugin know on what host's MIDI Channel it's on?
On Thu, Oct 16, 2014 at 2:21 PM, Phil CM <philcm(a)gnu.org> wrote:
On 16/10/14 19:02, Bill Gribble wrote:
what makes you think that Calf MonoSynth knows what track or channel it is
in?
Here's a vote for anything (lv2 extension,
OSC convention, or something
else) that makes information about how a host is using a plugin available
to the plugin.
This kind of introspection is useless for most plugins, but those that
need it can't get the information any other way.
Indeed, "most plugins" seem to get this in information as to what track
they are in (Calf MonoSynth, randomly) so how do I implement that in "my
plugin"? :)
9:44 p.m.
On Thu, 16 Oct 2014, Bill Gribble wrote:
Here's a vote for anything (lv2 extension, OSC
convention, or something else) that makes information about how a host is using a plugin
available to the plugin.
You can not in any case know that there is not a midifilter outside of the
host. Any MIDI event includes channel info that can be used in whatever
way the designer feels like. If the user filters the MIDI stream in some
way, they still want downstream SW to deal with the resulting MIDI as if
that is the way it had been created in the first place... so it is really
not the business of downstream SW know how the MIDI stream came to be like
it is when it enters that SW.
--
Len Ovens
www.ovenwerks.net
17 Oct
17 Oct
9:25 a.m.
On 16/10/14 20:39, Paul Davis wrote:
On Thu, Oct 16, 2014 at 2:21 PM, Phil CM <philcm(a)gnu.org
<mailto:philcm@gnu.org>> wrote:
On 16/10/14 19:02, Bill Gribble wrote:
Here's a vote for anything (lv2 extension, OSC convention, or
something else) that makes information about how a host is
using a plugin available to the plugin.
This kind of introspection is useless for most plugins, but
those that need it can't get the information any other way.
Indeed, "most plugins" seem to get this in information as to what
track they are in (Calf MonoSynth, randomly) so how do I implement
that in "my plugin"? :)
what makes you think that Calf MonoSynth knows what track or channel
it is in?
The fact that when I put it on a MIDI track (and the hosts decide witch
MIDI channel this track sends messages on) I can hear it without telling
him said channel (and I only hear it on that track)..?
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
10:13 a.m.
On Fri, 17 Oct 2014, Phil CM wrote:
On 16/10/14 20:39, Paul Davis wrote:
Indeed, "most plugins" seem to
get this in
information as to what track they are in (Calf
MonoSynth, randomly) so how do I implement that in
"my plugin"? :)
what makes you think that Calf MonoSynth knows what track or channel
it is in?
The fact that when I put it on a MIDI track (and the hosts decide witch MIDI
channel this track sends messages on) I can hear it without telling him said
channel (and I only hear it on that track)..?
I would suggest that Calf Monosynth is channel agnostic. That is it
ignores the channel information and uses midi events for any channel.
However in this case it only plays midi info for one channel because that
is all the host sends.
If I load The Calf Jack Host with the monosynth, it will respond to any
channel from the keyboard. Calf jack host does no filtering. However if I
run it through qmidiroute with only channel 1 enabled I get no sound
when the keyboard is any channel but 1.
--
Len Ovens
www.ovenwerks.net
10:26 a.m.
New subject: [Bulk] Re: How can a LV2 plugin know on what host's MIDI Channel it's on?
On Fri, 2014-10-17 at 08:25 +0100, Phil CM wrote:
The fact that when I put it on a MIDI track (and the
hosts decide
witch MIDI channel this track sends messages on) I can hear it without
telling him said channel (and I only hear it on that track)..?
Len explained it ;). Omni mode:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2014-October/035575.h…
10:33 a.m.
New subject: [Bulk] Re: How can a LV2 plugin know on what host's MIDI Channel it's on?
On Fri, 2014-10-17 at 01:12 -0700, Len Ovens wrote:
I would suggest that Calf Monosynth is channel
agnostic. That is it
ignores the channel information and uses midi events for any channel.
Len explained it ;). Omni mode:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2014-October/035575.h…
It can be tested, if it is done that way, by recording or editing two or
more channels with one Qtractor MIDI track. Btw. Qtractor's track
properties dialog allows to select channel 1 to 16, while other
sequencers might provide to select from 1 to 16 + any or all, Qtractor
provides to check "omni".
15 Nov
15 Nov
6:55 a.m.
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.
If the host is doing specific channel filtering and such anyway, what's
won by telling the plugin about it?
Just play all channels, i.e. ignore the channel entirely (omni).
Also, is there a way to tie the "volume"
controller of the host (in
Qtractor's case, the volume fader of the mixer strip) to one "volume"
control port of the plugin, thus removing the need for the "control
mode" control port ?
You can designate a port as volume in the metadata, but AFAIK no hosts
actually do anything with such information. Particularly since...
Yes because you see, here in my Qtractor (latest SVN -
but it has always
been that way) I can either edit the plugin (about 50% of my plugins
behave that way) controls but then the mixer's volume is inoperant, or
control the volume w/ said mixer but NOT the plugins controls. How can I
have my cake and eat it?
... 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.
--
dr
10:56 a.m.
On 11/15/2014 05:55 AM, David Robillard wrote:
On 2014-10-16 11:42, Phil CM wrote:
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).
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.
If the host is doing specific channel filtering and
such anyway, what's
won by telling the plugin about it?
Just play all channels, i.e. ignore the channel entirely (omni).
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.
hth.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Also, is there a way to tie the
"volume" controller of the host (in
Qtractor's case, the volume fader of the mixer strip) to one "volume"
control port of the plugin, thus removing the need for the "control
mode" control port ?
You can designate a port as volume in the metadata, but AFAIK no hosts
actually do anything with such information. Particularly since...
... 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.
9:04 p.m.
On 2014-11-15 04:56, Rui Nuno Capela wrote:
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
On 11/15/2014 05:55 AM, David Robillard wrote:
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.
On 2014-10-16 11:42, Phil CM wrote:
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). 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.
... 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.
3458
days inactive
3488
days old
linux-audio-dev@lists.linuxaudio.org
12 comments
7 participants
participants (7)
-
Bill Gribble -
David Robillard -
Len Ovens -
Paul Davis -
Phil CM -
Ralf Mardorf -
Rui Nuno Capela