I’m experiencing an issue where GP Relayer seems to ignore Program Change (PC) messages from my DAW (Reaper). Here’s an outline of what I’ve been doing and the issue I’ve encountered:
Original Plan: My goal was to route Program Change messages through GP Relayer to the local MIDI port in order to automatically trigger rackspace variations bindings. When this didn’t work as expected, I added MIDI monitors on both the Reaper side (before GP Relayer) and on the Gig Performer side to track the messages.
Observations:
Reaper Sends:
[CC 0 Bank Select MSB] Channel 1, Value 0
[CC 32 Bank Select LSB] Channel 1, Value 0
[Program Change] Channel 1, Value 2
GP Relayer Output (as seen in Gig Performer’s MIDI Monitor):
CC 0 Bank Select: 0 Channel 1
CC 32 Bank Select (fine): 0 Channel 1
The Program Change message does not seem to pass through GP Relayer.
Additional Context:
I reviewed the Global MIDI Options under Program Change Control in Gig Performer. While I can see physical devices and the local MIDI port, GP Relayer is not listed as a selectable device for Program Change control.
I also tried setting “Accept Program Change from any device”, but it appears that GP Relayer might not be categorized correctly as a MIDI device, and thus the Program Changes are not being forwarded as expected.
Request for Help:
Is this the expected behavior of GP Relayer, or is this potentially an oversight in how Program Change messages are handled by it?
Is there a workaround that would allow GP Relayer to pass Program Change messages to the local MIDI port?
Any additional troubleshooting steps or suggestions would be greatly appreciated.
I can confirm your findings that the Relayer output when receiving Program Change messages is only CC 0 and CC 32.
A few things:
GP Relayer is a plugin, not a MIDI device. So its not ever going to be categorized as a MIDI Device or a selectable device for Program Change control.
Hard to say. I tried the same experiment using Blue Cat Connector, which performs a similar function as GP Relayer, and got the same result-- CC 0 and CC 32 but no PC message.
It’s tricky because Program Changes in GP get interpreted at a core level, as they are the base for changing rackspaces. Since GP Relayer is a plugin, it could be that the PC messages get intercepted before they ever reach the plugin. You’ll have to hear from a developer on the exact details of this issue though.
Included GP relayer to send messages
Included GP relayer to receive messages and connect the MIDI Out to MIDI Out (Local GP Port)
Included a Widget to send a PC message to the MIDI In connected to the GP Relayer which sends messages.
Now I send PC 10 message from the widget and then the rackspace variation (assigned PC 10) was switched.
So I absolutely do not get the issue, or do I miss something?
GP Relayer is a plugin, not a MIDI device. So it’s not ever going to be categorized as a MIDI Device or a selectable device for Program Change control.
Got it, that makes sense! Even if that’s the case, I feel like external MIDI should still pass through some system port or channel into plugins like this one or Blue Cat Connector. Then, a virtual device could be mapped in Program Change control settings or considered when “allowing from all devices.”
It’s tricky because Program Changes in GP get interpreted at a core level, as they are the base for changing rackspaces. Since GP Relayer is a plugin, it could be that the PC messages get intercepted before they ever reach the plugin. You’ll have to hear from a developer on the exact details of this issue though.
Yeah, that makes sense. The only workaround I’ve come up with so far is using scripting to remap from and to CC on both sides—DAW and GP. In the DAW, it’s mainly to avoid the hassle of remapping previous automation since I’m migrating to GP.
I’m just wondering if there’s a way to suggest this improvement. It seems like a logical and useful enhancement, especially for automation and DAW integration.
Also, I feel like system plugins, like GP Relayer, might be handled differently from their VST/AU counterparts when used externally. It’d be great to understand more about how GP manages this internally and whether there’s any flexibility to improve how Program Change messages are processed. For instance, maybe this issue is not reproducible when using two instances of GP Relayer in Gig Performer.
If you read some of the responses in the other thread, I think the answer why they don’t pass is about VST3—sadly, it is a known limitation to that plugin format. (I had forgotten that, honestly)
You can do a web search on VST3 and Program Change and you’ll see endless comments on various forums lamenting this limitation. So its not really about GP not handling the messages correctly. It can only handle what the plugin format allows.
When you use GP Relayer within GP itself, its not using that same VST3 plugin, which explains why it works internally, but not when using an external source.
Interesting, I’m wondering if GP Relayer as a Gig Performer system plugin is exactly the same as the VST/AU counterparts we use in DAWs. Could you try performing the same test from a DAW using GP Relayer VST3, where the DAW sends the Program Change to Gig Performer?
Another useful test could be to set up two separate instances of Gig Performer and check if the Program Changes are passing through between them.
If Program Changes are passing through GP Relayer across multiple Gig Performer instances but not in the DAW, that suggests the GP Relayer plugin is different from its VST/AU counterpart. If it doesn’t work from both the DAW and multiple instances, it supports my original theory that Gig Performer’s core system “Program Change Control” is blocking Program Change messages to unknown devices not listed, like plugins. However, if it works from the DAW, then my theory is incorrect.
Yes, this is it!! I just ran a test using the AU version, and it works perfectly. So the issue seems to be specific to the GP Relayer VST3 wrapper, as the problem is reproducible only in that format.
Both the GP Relayer AU and the GP Relayer System are passing Program Change messages correctly, so it looks like the VST3 version is the one causing the trouble.
At least we’ve narrowed it down to that; since I use only Mac, I’m very happy with this solution. However, it would be great if, in the future, they release a CLAP version of the plugin so Windows users can get the workaround.
Thanks again for your help in troubleshooting this!