Greetings! I am considering purchasing Gig Performer, downloaded the 14 day trial and am impressed with it’s feature set. However, there is a key implementation application that I have not been able to resolve.
My application. I am the Music Minister at a local church. My primary instrument is guitar but I also play keyboards. I primarily lead worship playing guitar and singing while directing the choir and our praise band. I am playing a JTV Variax outfitted with a Fishman TriplePlay. The guitar is connected via VDI to a Line 6 Helix. The FTP drives a MacBook Pro which is using the Helix as an audio interface via USB. This is a powerful setup, but with that power comes complexity. I want to have a consistent and predictable rig configuration that I can easily update/change since we perform all new music every week.
Specifically, I would like to be able to map the Helix’s snapshots to Gig Performer’s Variations (which are basically snapshots as well). Each snapshot on the Helix can transmit CC messages and/or patch changes as well as other data. Unfortunately, it appears that GP’s Variations only respond to patch changes. When I step through consecutive patch changes on the Helix, GP only advances through the Rack spaces and ignores the Variations.I tried setting up snapshots to send patch changes, GP also only advanced through the Rack spaces and ignored the Variations. This is frustrating.
The Helix can have up to 8 snapshots within a single patch. It would be nice to be able to map those to GP Variations so that I can localize all changes for a given song within a single Helix/GP patch. GP allows for “move up/down” under global midi, but this would not implement well with switching back and forth between snapshots - they would always need to be sequential.
Do you have any suggestions? Is there some other way to select variations?
I’m not sure I understand the issue here. You can absolutely assign program changes to variations. In fact technically, you can assign program changes ONLY to variations (there is always one variation selected in a rackspace). By default, a program change is only assigned to the first variation of a rackspace but all you have to do is double-click on a variation itself and you can associate it with a program change (see attached image)
Thanks for the quick response. But no, it didn’t help.
The behavior you just described does not occur. To test, I created 4 Racks that have 3 Variations each. Consecutive patch changes sent by the Helix only advances through the Rack spaces and ignores(skips over) the Variations. This is true whether the Helix sends them via actual patch change or via snapshots.
More importantly, even if this methodology did work as you describe and I set up my first patch and assigned consecutive MIDI patch numbers to each of the 8 snapshots, I would run into conflicts as soon as I needed to switch actual patches on the Helix. Please observe the conflicting the attached photo.
This methodology WOULD work if the snapshots could send PC’s to Variations on a different MIDI channel, but when I tried this GP again just skipped over the Variations to the next Rack.
Thus I conclude that I need to be able to be able to change Variations via another method (like CCs).
Ashley, I’m completely lost here — if your Helix is sending program changes, and you have variations configured to receive program changes, then it HAS to work. I don’t know what a Helix “snapshot” means but I’m suspecting that your Helix is NOT just sending program changes. What do you mean by a “consecutive patch change”?
Can you please open Gig Performer’s Global MIDI Monitor (from the Windows menu), then send some “snapshots” into Gig Performer and then paste here the information displayed by the MIDI Monitor please?
The Helix works in the following manner. Like most MIDI devices, there are memory locations called patches. Each patch corresponds to a MIDI program change. Each patch on the Helix can have up to 8 snapshots. These are states of the patch (i.e. which resources are turned on, the state of assigned parameter settings, current state of signal flow for various inputs and outputs, etc.). Additionally, the Command Center allows you to send additional parameter values for things like CC messages, patch changes to external units, CV values, toggle states for externaL devices (such as guitar amplifiers) via a 1/4" TRS jack.
So each memory patch (and thus PC) can have 8 snapshots that radically alter the state of the patch. That’s 8 different states (or Variations) within a single memory location with a single PC value (say PC 01). So all the states needed for a single song exist within a single patch (memory location). So a Patch is analogous to a Rack and a snapshot is analogous to a Variation in terms of functionality.
EXCEPT that it seems the only way to change Variations within a Rack is with PC messages. The Helix changes 8 snapshots within a single PC location.
If Variations could be advanced with a CC value, then GP could track the Helix’s snapshots without being tied to a PC. Is this possible?
Why it doesn’t currently work: Within a patch I CAN assign consecutive patch changes within each snapshot via the Command Center. In my photo example, this is shown as requiring PC #1-9. As long as I stay within that patch it would work fine. But as soon as I advance to the next patch, PC 2, we’ve got a conflict because GP would map this back to a Variation in the first rack instead of advancing to the NEXT rack. You see?
So are you telling me that when you change snapshots, you can’t send specific program changes out? Suppose you wanted your Helix to control an external synth that expects program changes to change its patch? How would you do that?
Can you not do the following with the Helix?
Patch 1
Snapshot 1 --> send PC 1
Snapshot 2 --> send PC 2
Snapshot 3 --> send PC 3
Snapshot 4 --> send PC 4
Snapshot 5 --> send PC 5
Snapshot 6 --> send PC 6
Snapshot 7 --> send PC 7
Snapshot 8 --> send PC 8
Patch 2
Snapshot 1 --> send PC 9
Snapshot 2 --> send PC 10
Snapshot 3 --> send PC 11
Snapshot 4 --> send PC 12
Snapshot 5 --> send PC 13
Snapshot 6 --> send PC 14
Snapshot 7 --> send PC 15
Snapshot 8 --> send PC 16
Or alternatively, set the variations for each rackspace to use different banks and do something like the following:
Patch 1 --- Send Bank 0
Snapshot 1 --> send PC 1
Snapshot 2 --> send PC 2
Snapshot 3 --> send PC 3
Snapshot 4 --> send PC 4
Snapshot 5 --> send PC 5
Snapshot 6 --> send PC 6
Snapshot 7 --> send PC 7
Snapshot 8 --> send PC 8
Patch 2 --- Send Bank 1
Snapshot 1 --> send PC 1
Snapshot 2 --> send PC 2
Snapshot 3 --> send PC 3
Snapshot 4 --> send PC 4
Snapshot 5 --> send PC 5
Snapshot 6 --> send PC 6
Snapshot 7 --> send PC 7
Snapshot 8 --> send PC 8
Another possibility - can your Helix send CC messages (say) representing UP and DOWN as you go from one snapshot to the next? If so, you could use Gig Performer’s Global MIDI controls to go up and down.
Finally, if all bets are off, you could most certainly create simple scripts with Gig Performer’s programming language to set the variation based on a CC message, for example, if you create a MidiIn block and give it the GPScript name, “MyHelix” then you could use the following code in a script to respond to incoming CC messages on CC number 12.
var
MyHelix : MidiInBlock
On ControlChangeEvent(m : ControlChangeMessage) Matching 12 from MyHelix
SetVariation(GetCCValue(m)) // Change the variation number as an offset from incoming CC number ---
End
Given that I have completely different songs each week, either of your examples would be a tedious weekly chore. I need something that I can set as a template that makes it easy to create a set for each week. Both scenarios also ignore that fact that each Helix Patch sends it’s own PC on it’s base MIDI channel. So it seems the short answer is “no,” GP cannot accommodate this. In the universe of MID and Automation, it seems like a significant limitation that the Variations can only respond to TWO kinds of messages.
Maybe you can unpack the programming language script for me. I am not a programmer and it would be helpful to know what term fields do what.
Otherwise, I will just have to create rack panels that use widgets to execute CC changes triggered from Helix Command Center.
In the Gig Performer world, each variation can be associated with a unique combination of (optional bank number) and program change number. Essentially, variations ARE the patches in Gig Performer.
Variations can also respond to OSC messages (either by number or even by name!), you can also go UP/DOWN, either globally, or restricted to a particular rackspace, using two MIDI events of your choosing. You can use GP Script to make variations respond to arbitrary information (change to variation 3 if you receive three specific MIDI events one after the other and it’s Tuesday after 7pm) so it’s pretty flexible.
From my perspective, it seems like it is the Helix that has limitations!
It might be easier to discuss this by phone, perhaps there’s something I’m not understanding. Please open a ticket at https://gigperformer.supportsystem.com/ and send me your phone number (and location) and I’ll give you a call.
Hi! Sorry for the necrobump, but I’m running into a similar issue with Helix Native and Snapshot selection.
According to the Native manual, MIDI CC 69 commands perform this function in the plugin, with values from 0 to 7 selecting snapshots 1 to 8, respectively:
I created radio buttons in my Rackspace and set them to send MIDI messages in the proposed way, however the behavior has been very erratic. I believe this is due to the scaling system used by Gig Performer. Sometimes it reads correctly, while other times the commands are completely ignored by Helix Native.
I imagine that the problem is in the scaling system used by Gig Performer. I say that because, if I use the Setlist function and program each Song Part to specifically send a MIDI 69 message (with values from 0 to 7), Native reads the snapshot changes perfectly:
However, when I do this via rackspace, I get back to the problem of it not recognizing the messages correctly.
Therefore, I would like to know if it is possible to send a message with CC 69 and the specific values, skipping the scaling system of the widget properties tab.
I would be grateful if anyone could help and I apologize if I was not clear enough in my explanation.
The widget scaling system can easily map to a midi value by entering the value using an “m” suffix e.g. entering 7m will convert to the equivalent of midi value 7.
When using radio buttons for this, you also need to disable the setting in the Value tab of the widget properties to send a value when the radio button is in the Off state (otherwise each button will select the first snapshot when switched off).
Were you aware that there is an automation parameter in Native for the snapshot selection? So you can use this instead of sending midi.
Also, there is a great user gig file template for Native that has the snapshot selection already set up.
I was not aware of the m suffix, this makes life with Gig performer a whole lot easier!
Also, I was not using the automation parameter (Snapshot Index) because I was facing similar issues with scaling messages.
I tried using the that Line6 Helix Native rackspace posted by npudar earlier this week. Although it worked great in rackspace mode, once I switched to preset view it constantly crashed on my PC and Mac. I sent a few crash reports via Gig Performer and thought it could be something related to my other plugins, but once I started operating Native through MIDI CCs the problem went away.
Strangely, every time I open Gig Performer I am greeted with a message saying that the plugin was not found and that it is disabled. However, it’s working as intended and the message goes away once I select the rackspace:
