Can MG3 be configured *not* to listen to Program Changes?

BETA TESTING
,
1

I am seriously happy to have MG3 able to respond to Program Change (PC) messages, but there are times when I’d actually want to use an instance of MG3 that doesn’t listen for such changes, or at least restrict its listening to one MIDI channel. Is this possible?

I’ve been giving AUM Mixer on iOS a real workout lately (and…loving it) and I’d really like to be able to use its ability to load plugin presets (not MG3 specifically, but other plugins) with PC messages on specific channels, but MG3–all instances of MG3–happily responds to anything from any channel.

I think this effectively means that either I can use multiple instances of MG3 (running different patches) and not use PC messages, or I can use one instance of MG3 and use PC messages, understanding that MG3 is going to respond to any PC message sent in the AUM Session.

2

I’ve raised this before. It would be very useful to be able to select the source of MIDI PCs vs input for other MIDI devices, or block MIDI PC altogether, if desired.

Having said that, MG3 will only respond if you send the PCs directly to the plugin – you’re using MG3 as an AUv3 in AUM, right?

Possible solution: If your controller that sends PC is dedicated to that function alone and has it’s own system level MIDI port, you could set that controller as the main source under Controllers and then use the MIDI Device module in a chain if you need seperate expression control (via CCs from another unique device). N.B., the MIDI device won’t receive/pass PCs. But this is just me thinking out loud, so to speak.

If you give me a signal flow of your rig/MIDI connections, I’ll see if I can think of a decent way to work around it for you until such time that this feature could be implemented.

3

Thank you kind Sir for your thoughts here. On reading the above, I thought “Hm, I suppose I am typically using AUM’s MIDI Routing feature to port my tabletop and floor controllers specifically to MG3”, just to simplify things*". Certainly an idea worth testing!

THE SETUP: And so today, I set up an atomic-level AUM PoC session consisting only of two Audio channels, one taking hardware input and running thru MG3 with no audio output destination, and a second one taking SampleTank (as an example of a plugin which can respond to PCs) and sending to hardware output, with the only MIDI Routing connection being connecting MG3’s MIDI output to SampleTank’s MIDI input.

image

image

If I’m understanding your thinking, this should be the best possible atomic test of the idea that MG3, as an AUv3 plugin, should not respond to incoming PC (or any MIDI control) because I’ve not created any mapping or routing that would actually send control messages (PC, in this case) from the host (AUM) into the plugin (MG).

THE TEST: Notes played into MG3 come out perfectly normally, and I can hear SampleTank’s output as expected. Lovely. I then programmed three switches on my AIRSTEP floor controller, to send PC messages on three different MIDI channels (channels 1, 2, and 12 FTR; I figured I’d try the normal control channel, a typical MPE channel, and a beyond-MPE-for-guitar channel), and you’ll note there’s no routing instruction for that AIRSTEP in the MIDI Routing pane.

THE RESULT: MG3 happily responded to the PC messages from the AIRSTEP every time. To me, it looks like MG3, even operating as a plugin, is listening independently for PC control at least, and regardless of channel. I even tried going through MIDI CTRL > CHAN1 > MIDI Guitar > … (the ellipsis right beneath the All/Assigned/Unused filter, where the plugin name appears) and explicitly Set MIDI Channels (I tried filtering to channel 4 FTR) and the result was the same.

I’m more than happy to see how I missed something here. Any ideas?

*I have typically been setting up three MIDI bus objects in my AUM sessions: one representing all my tabletop controllers, one representing all my floor controllers, and one representing all my MG3 instances. In larger sessions this has been handy in terms of being able to add/remove from these buses without affecting the rest of what’s in the session.

4

At this time, if you do not want MG3 (AUv3 or Standalone) to listen to MIDI PC messages, in the MG3 MIDI Patchbay you must select either “No MIDI Controller” or a MIDI input device that doesn’t transmit PCs. MG3 only listens for MIDI PCs on the port(s) that you allow. There is no channel restriction implemented.

MG3 is somewhat unique in this manner. I don’t think many plugins have this kind of MIDI implementation whereby the plugin itself is handling it’s own MIDI I/O rather than the host/DAW.

You can also use a MIDI Device module in a chain to receive other controller data, if needed as these devices do not handle MIDI PCs.

5

Wow, you really do help my general understanding of things with these insights. I much appreciate that, thank you!

The first thing I saw, when I went to test these ideas, is that I hadn’t even noticed the MG3 Patchbay has a “MIDI control from DAW” option (as well as one for “AUM”, which I hadn’t looked for either), at least when operating in plugin mode. That right there altered my thinking in a useful way, even though it’s not what I was there to test.

I then began playing with things, starting with your specific scenario of “No MIDI Controller” on the Patchbay and a MIDI Device module set to receive from my floor controller “AIRSTEP”, which sends both CC and PC.

INSTANT FUNCTIONAL SUCCESS. This, I can make work!

Okay, the nerd in me may still think it would be more elegant, to refine the MG3 control settings a bit further, but this 100% gets me what I’m really after, here: the ability to create an MG3 patch which itself will not listen to PC sent from floor, but will still accept floor CC from the same controller. It works! In this case I can now send PC from the AIRSTEP, and MG3 will ignore it while SampleTank will respond to it. (And this also opens the door to effective use of PC-based plugin preset loads in AUM, and multiple instances of MG3 in which some listen for PC, but others do not.

Functionally, that’s the whole enchilada.

In playing a bit to truly “find the edges” of this idea, I can confirm that once you open up any mapping for a controller to reach MG3 at all (whether via AUM as host, or directly via the Patchbay), then the Patchbay indeed listens for PC on all channels. But it should prove pretty flexible, to have the Patchbay set either to “no controller” or to my tabletop controller (from which I’m not sending PC), and then use MIDI Device for floor controllers. I’ll have to rethink my MIDI bus architecture (in AUM) to make this elegant, but this is worth doing that.

Incidentally–not that it’s critical here–how would one go about specifying MIDI listening ports in MG3, either iOS or macOS, and standalone v. plugin?

6

Ah, so here’s the “too good to be true” wrinkle. Not surprising, I guess, that there would be one. :upside_down_face:

The Patchbay’s setting for MIDI controller is global to MG3, isn’t it? Like the “next patch” and “previous patch” CC mappings, it is global for all patches, whereas the nine Patchbay message slots are local to each patch?

Presuming that’s true–it seems to be, in initial testing–then okay, I’ll just have to rethink a few more things. It’s still a much better state to be in than before, but no longer truly the whole enchilada.

7

I forgot to mention this. Glad you found it.

Excellent!

It should be the same. The user always selects the port(s) under the menu in the MIDI Patchbay or the MIDI Device module.

Yes. I believe that is the case.

8

I’ve just been playing with AUM (iPadOS) a little bit and I think it’s worth adding that there are extensive MIDI control parameters available, although they’re a little below the surface (under the MIDI Routing section). If you’re using “MIDI control from DAW” under the controller section in MG3, you can filter some MIDI input, such as channels and message types. The MG3 plug-in will then only respond to the messages/channels you allow. In the attached images, I blocked MIDI PCs from being sent to MG3. I also tested restricting the channel. Both work.

IMG_0190.PNG
IMG_0190.PNG1920×1439 116 KB

IMG_0191.PNG
IMG_0191.PNG1920×1439 118 KB

9

That’s a great point, thank you. Turns out I had run across and even tried that filtering already–but that was before I had realized that I could tell MG3 to only take control from the host, and I obviously forgot about it after concluding it didn’t get me what I needed. So, this reminder is much appreciated!

And with that shiny bit of context, that really brings back the whole enchilada, for what I’m wanting to do here. And it’s even the “right” answer, too, from the principle and design angle–because the host can be the ultimate control over command and dispatch, leaving true preset/patch management and organization to the individual plugin. (I’m enough of a design nerd to appreciate that. :nerd_face:)

10

Good call. It should be easy to add as an option somewhere to disable listening on PCs. I have put it on the list.

2 Likes