Mapping the MC6 Pro in Gig Performer to switch Helix Native presets

Morningstar Gear MC Pro Series MIDI Controller
1

With the generous support of someone in the Gig Performer forum, I was able to map 5 widgets to switch between 5 presets in Helix Native, plus one widget to turn it on and off, i.e., to bypass it.

Now I’m trying to tie them to the 6 switches of a brand new MC6 bank and, so far, though I tried a bunch of things, I can’t manage to get it to work.

I’ll share a couple images of what the GP5 window looks like where one programs the MC6. If anyone has any experience with doing the same or has some idea of how it can or should be done, I’d greatly appreciate it.

[Album] imgur.com

PS: In GP5, changing presets in Helix Native is achieved by creating an IAC Driver, assigning PC# 155 to it, then programming a different “value” for each widgets.

2

I think you may be doing this in a way that’s more complicated than necessary.

The advice on the GigPerformer forum you received was good and accurate and all that, but wasn’t really the easiest way to do this.

This is logically what I would do, given what you’re trying to achieve:

  • have your MC6 Pro send PC (program change) messages because that’s all Helix Native will accept
  • pass them directly from the MC6 Pro through GigPerformer into Helix Native
  • set up the GigPerformer options such that it will allow those messages to pass through to Native
  • important: you need to pick your starting preset number so it is higher than the number of rackspaces you have in GigPerformer. This is because GP inherently assumes that PC messages are intended for GP. So if you have rackspaces numbered 1-25 then GP will assume PC messages 1-25 are intended for GP, even if you tell GP to ignore PC messages.

I don’t use Helix Native, but TH-U will accept PC messages to change presets, so the images I’m about to show you work for routing PC messages through GP to a VST (in my case TH-U, yours will be Helix Native).

First, insert the following midi wiring into your global rackspace if that’s where you’re going to run Helix Native:

image
image364×284 20.9 KB

You don’t need the midi monitor block in there, but that will show you if your PC messages are getting sent to Native.

Second, in GP go to Options->Global Midi and set the PC messages options at the bottom as the image below:

image
image683×713 69.9 KB

You MUST set the checkbox for your MC6 MIDI In (generally best to use the second port, but the first should work as well). You MUST check the box for passing unused PC messages through.

Once you’ve set those options the trick is to send PC messages that are higher than what GP automatically assigns to your rackspaces. I rarely have more than 20 rackspaces myself, so if I were going to do what you’re doing I’d start the Helix Native presets at PC 30.

The last step is just to go into your MC6 Pro editor and have it send PC messages for each of the footswitches you want to use for that.

image
image966×232 13.3 KB

That should be all there is to it. For me (on Windows, using Th-U) that’s all there is to it.

In Helix Native you’re going to have to set the presets you want to align with those PC messages. In Th-U I can’t arbitrarily assign presets numbers. They get automatically assigned in order, so I just have to drag the presets I want to slots 30 through whatever. If it’s a new bank I’m using I just have to put 29 empty presets in front of it.

I know it’s been said in the GP forums to you already, but I’ll repeat it. This isn’t how either GP or Helix are designed to work. Most VSTs do not accept PC messages, and the ones that do often produce a lot of audio glitching when changing presets. I understand you want to run Helix in the global rackspace for the reasons you explained, so this approach should work for that.

Your better alternative would be to run a second instance of GP just for your guitar, and put your five different Helix sounds in five different rackspaces. Then you’d use the MC6 to change Rackspaces.

But if the approach described above works for you, great.

3

A couple afterthoughts to all that…

With this approach you lose the visual feedback of the widgets. If that’s important to you, then there are other approaches.

I think all of this would be better handled through GP’s scripting language. That gives you a lot more flexibility, but you’d kind of have to know what you’re doing with the scripting. It’s not that high a hurdle to learn the basics if you’ve ever written code before. But if coding is entirely new to you it could take some effort.

1 Like
4

@Vindes Your post didn’t go unnoticed, it’s just that I’ve been busy elsewhere.

First, thanks. It does work—while I couldn’t get it to work with the other approach. So, after spending hours on this, that’s good news. I have it working with a GP5 test gig file, so all I have to do now is port it over to my original gig file.

You write “This isn’t how either GP or Helix are designed to work. Most VSTs do not accept PC messages, and the ones that do often produce a lot of audio glitching when changing presets.” I haven’t tested things yet, I just programmed it. I’ll do so soon and we’ll see about whether it glitches or not.

The idea of using a second instance of GP and simply switching rackspaces with each holding a different Native preset is clearly interesting. I’d need to make some test with that too, it would be easy enough, and see what the hit on my CPU looks like (I never ran 2 instances of GP simultaneously and I’m curious about that).

About the visual feedback, it’s OK if I don’t get that. If it all works fine, I’ll hear what preset is on. Plus, there’s a way to toggle a visual feedback on the state of the switches on the MC6, so I could look into that if needed.

Scripting and coding… I know nothing of that, but you make me curious. Can you say a few things as to why “all of this would be better handled through GP’s scripting language”?

In any case, thanks again for having taken the time to share your solution. I really appreciate it.

5

The main issue with your specific situation is that Helix Native seems to only accept program change (PC) messages to do the preset switching. There’s no way to tell it to use something else, like note-on messages or CC messages, etc.

GigPerformer treats PC messages differently than everything else, because GigPerformer is built to use PC messages to change Rackspace, just like Native will change presets. While there are other ways to do it in GigPerformer you can’t change the fact that GP is going to intercept them. This means you have to make sure you’re using a range of PC messages that GigPerformer isn’t going to intercept and refuse to pass through to Native.

In general I avoid using PC messages for anything because there are too many legacy midi quirks like this.

If I were trying to do it I’d set up the MC6 to send CC or note-on messages. Doesn’t really matter which. The point is just that nothing is going to interfere with those the way things sometimes do with PC messages.

I’d have a script that looks for a particular CC message - let’s just pick CC 10 - and looks at the value in that message (0-127) and then directly sets Native to that preset.

There other ways to do it as well using widgets without any scripting. But, again, the real issue is that GigPerformer is designed around the fact that most VSTs do not handle live preset switches well. The point of Rackspaces and Variations is to allow you to switch instantly and seamlessly between different collections of plugins without audio glitching.

I have some guitar rackspaces in GigPerformer where I’d have the equivalent of six different instances of Native in my global rackspace. They’d all be running in parallel and I’d just select which one(s) is audible using a mixer plugin. How practical that is depends on how much CPU each instance of Native takes up.

But given what I think you’re doing, I’d just put Native in a separate instance of GigPerformer. That way you can switch that instance between rackspaces independently from the rest of the stuff you’re running.

But do what works for you. There’s a learning curve with all this stuff, so starting with what works is fine. At some point if it’s not working, then you learn how to do it a different way.

1 Like
6

@Vindes OK. So now I get somewhat get that there’s an inherent issue with using PC messages with GP to do something with Native.

You write “If I were trying to do it I’d set up the MC6 to send CC or note-on messages. Doesn’t really matter which. The point is just that nothing is going to interfere with those the way things sometimes do with PC messages. I’d have a script that looks for a particular CC message - let’s just pick CC 10 - and looks at the value in that message (0-127) and then directly sets Native to that preset.” I see. So, wWould sharing a basic script that does that possible? I have to ask. But maybe it’s too much to ask.

You also write “I have some guitar rackspaces in GigPerformer where I’d have the equivalent of six different instances of Native in my global rackspace. They’d all be running in parallel and I’d just select which one(s) is audible using a mixer plugin.” Interesting. You mean a GP mixer plugin? And how do you control it? How do you enable the different instances individually? With widgets? Or?

Native in a separate GP instance. Yes. As I wrote before, I’ll look into that.

As for “There’s a learning curve with all this stuff, so starting with what works is fine. At some point if it’s not working, then you learn how to do it a different way”. Right. No joke. I’m seeing that more every day since I’m relatively new to MIDI, to GP and to the MC6 Pro, which all offer so many possibilities.

I’m increasingly aware that I need to clarify what it is exactly that I want to achieve. So far, it boils down to what I’ve been able to do (switching things by hand) using Logic Pro, with Native for the normal guitar sounds and MIDI Guitar 3 for software instruments. Leaving aside the limitation of having to switch things by hand, which is what I hope I won’t have to do anymore by using GP and the MC6 Pro, one advantage of my Logic Pro setup is that it’s been allowing me to combine multiple software instruments to create unique sonic patches. Then the question becomes how to achieve that in GP? What is the most effective way in GP to have multiple software instruments playing all at once?

At this point, in GP I have separate software instruments in separate rackspaces. It works fine switching them with the MC6, but there’s no way to combine them. So I’ve been wondering about solutions.

What if I would put them all in, say, the Global rackspace, and use widgets to switch each of them on and off individually? That way I could have, say, 2 or 3 playing simultaneously. But that raises a question: When a bunch of them are “bypassed”, are they still “on” as far as the CPU is concerned? If you know the answer to this, I would appreciate hearing it.

If bypassing them means that they’re not active as far as CPU is concerned, that could be a solution for what I’d like to achieve. Then I could simply have 2 or 3 banks running with the MC6 Pro, with one tied to my Native presets in one instance of GP, and the other(s) tied to the Global rackspace of the first GP instance where I could freely switch on and off the software instruments. That way I could on the fly combine easily any of my Native guitar sounds with any single or combined software instruments.

All that said, I need to experiment with those ideas. And again, as you write, “At some point if it’s not working, then you learn how to do it a different way”. Yes, hopefully.

Thanks again for your support.

7

@Vindes PS: After researching posts in the GP forum, it looks like actually “bypassing” plugins in a single rackspace does render them inactive as far as CPU is concerned. So I’ll create a brand new setup and experiment—using 2 instances of GP, with one running Native presets, the other software instruments, and program new banks on the MC6 to control them.

8

It’s not too much to ask, but unfortunately I don’t really do GigScript. There was a time that I did, what seems like 5 years or more ago, but since GP introduced an external API I do just about everything I want to do through that.

I’m an unusual Morningstar user in that everything I do with guitar runs through GigPerformer, so I don’t need my MC’s to control anything else. I’ve written a few different GigPerformer “extensions” that interface GP to different “control surfaces”. The MC series is one such set of “control surfaces.”

My MC extension for GigPerformer is on GitHub here: Morningstar MC8 GigPerformer extension. It says MC8, but it’s for the MC6 & MC8 and the Pro versions.

My objective in writing “control surface” extensions like this is to move all of the logic and coding into an external highly configurable application (the extension) and make all of it configurable through the GigPerformer gig file. The really simple overview is that it turns the MC6/8/Pro into just a “dumb” interface that displays what the extension tells it to display, and the MC just tells the extension what buttons are pushed. Everything exists in one MC Bank, and that bank has to be set up to send the midi messages the extension expects for each button press.

There’s documentation in the GitHub repository. It’s not particularly complicated, but does require some thinking and understanding to make it work for you.

I think it would work for your situation, but may not be the simplest approach.

If you wanted to try going this route I’d say start by setting up your six button widgets (or whatever you used) so that they work exactly how you want for controlling Native. Once you have that part working you just have to give those widgets specific names (in the OSC/GigScript field on the Advanced tab of the widget editor) that tell the MC extension how to map them to your MC6 Pro switch positions.

I’m not sure I completely understand that question. If you have three different VSTs that you want to sound at once you just drop them into the wiring view in parallel. e.g…

image
image788×330 45.7 KB

In that picture above I have four instances of GuitarArchitect in parallel, all sounding at once based on the same input. The main purpose of GigPerformer is to let you make your signal path as complex as you want it to be.

1 Like
9

@Vindes I’ll start with the end. When asking “What is the most effective way in GP to have multiple software instruments playing all at once?”, what I meant is how to freely combine them, so that one or two or more may be active while others are bypassed—so, in the image you shared, it would mean something like having only, say, GArch A and GArch D playing, while B and C are inactive or bypassed. As I wrote, while I need to experiment with this, it looks like I can have many software instruments in the same rackspace and simply switch whichever I want freely on and off using widgets set to “bypass”.

Now, about your extension… I just read some of the notes. Fascinating. “It’s not particularly complicated, but does require some thinking and understanding to make it work for you.” Right. I bet. I’ll experiment with the Gigfile you provide, at some point, and see where it gets me. One thing I noticed, which is interesting, is how this extension uses a single bank. That’s clearly a big plus, as opposed to having to navigate between banks in the normal way.

For now, I’ll first try what I wrote about, see how it goes and take it from there. That is, create a brand new setup using 2 instances of GP, with one instance running Native presets in separate rackspaces (while I could also use the method you shared using PC messages, which works), a second instance running software instruments in a single rackspace using widgets to freely switch them on and off, and then program new banks on the MC6 to control them. Let’s see how that works—as the blind man said.

10

Well, the original concept for GigPerformer (as I understand it) was that a “Rackspace” was intended to be whatever combination of plugins, plugin parameters, and routing to produce some particular sound. Very much like the equivalent of a Preset in something like Helix Native, but involving multiple plugins, complex routing, etc.

Widgets were a mechanism for adjusting specific parameters (e.g., delay time, chorus on/off) in real time, like the knobs and switches of a stomp pedal or drawbars on a Hammond B3 organ VST.

Variations were a mechanism to store “snapshots” of a Rackspace that would have all the same underlying plugins and routing, except the widgets would be in different positions. So one variation with Chorus on, one with Chorus off. The more Widgets you have controlling parameters, the more Variations you might want to make.

Because GP was entirely built for performing live, the mental model was more or less “if you want a different sound (for a different song or different part of a song) then create a different Rackspace.”

This thing you’re asking about, where you might want to bypass and unbypass things on the fly, can be accomplished in a few different ways. There is not one “best” approach.

One approach a lot of people use is having a Widget that toggles the Bypass of a VST. A common downside to that is some VSTs will effectively freeze their internal state when you do that. So let’s say it’s a reverb with a 6 second tail. You hit your chord, and then 2 seconds later you bypass your reverb. A few minutes later you un-bypass your reverb. Is it going to play back the 4 seconds of reverb tail from when you bypassed it, or does it purge that buffer and start fresh?

Effects plugins generally have their own on/off parameters, so you’d typically shut them off (like stepping on the pedal) rather than bypassing them.

This same thing also applies to instrument VSTs. If it’s MIDI based and you’re holding a note when you bypass it, the plugin is “frozen” while bypassed. So if you release the note while it’s bypassed it doesn’t know it. So when you unbypass it you may have stuck notes playing.

One approach is to run instrument plugins through a mixer plugin and just mute the appropriate channels on the mixer. The VST keeps doing its thing, but its output is muted at the mixer. Another approach is to block the VST from receiving input (either midi note-on events or analog signal). That way it will continue sounding whatever it was doing (e.g., the reverb tail or a chord played on a keyboard) but make no further sound after that finishes.

It really depends on the plugin and what you’re trying to do.

On most of my PCs I have way more processing power and RAM than I’m going to need, so I almost never bypass plugins. I’ll either mute them at a mixer or block incoming midi notes.

I’m not sure where it’s documented, but when you run multiple instances of GP at the same time each one will have its own “identity”. If you don’t name them in advance you won’t necessarily know what’s what.

On Windows you’d create a shortcut with a “target” something like

"C:\Program Files\Gig Performer 5\GigPerformer5.exe" -in="Guitar"

The “-in” part indicates the instance name. On systems where I run multiple instances I’ll have different desktop shortcuts for “Guitar”, “Keys”, and “Drums”. When you name instances like that, each instance name will remember all of its own settings, including what Gigfile to open, which midi devices to enable, etc.

In my case, my Keys instance is always going to have exclusive access to my keyboard midi ports, and my MC8 Pro is only going to talk to my Guitar rig. My vdrums are only going to be seen by the Drums instance.

You might initially think, “who cares” but it can definitely make your life easier, especially on windows (where most midi drivers can only talk to one application at a time, and different instances are different applications).

Like I said before, it’s not all that complicated once you understand how things work. But there are a lot of moving parts. The GP forums are among the best around as far as developer and real world support go. (As is this forum.)