SelectPartOrVar - SOLVED! (?)

General discussion about Gig Performer
1

I’ve been trying to figure out how to create a “macro stomp box” with Gig Performer 4. It seems that I could send Program Changes from my controller, but that’s old school. I’d like to do this with Widget switches on the Global Rackspace Panel and the Systems Action plugin. Then I can learn any MIDI message from the controller to trigger the Widget.

I found the SelectPartOrVar parameter. Is this feature not quite refined yet? There are no details in the manual just yet.

While typing this topic, I got it working, but it’s weird. I’ve added three widgets (button pads.) I’ve set each to the Systems Action: SelectPartOrVar parameter. I’ve given them custom labels of “Part 1”, “Part 2”, and “Part 3.” I’ve learned the controller messages, which are from three pads (notes) on my Akai controller. Pad Switch 1 is (in the Advanced tab) Param 1, Pad Switch 2 is Param 2, and so on.

Here’s the trick… I set the min and max of each control curve to the same value for a given widget in order to force a single value output. A min&max value of 0 selects Song Part 1. A value of 1 selects Song Part 2. A value of 2 selects… Song Part 4. Yes 4. I needed to set a value of 1.5 to select Song Part 3. Weird.

It seems that this could be improved. (Exercise left to the development team.)

The cool thing is that I got it to work and that I didn’t need to touch the default programming of the controller. It was just a matter of “learn” and “touch”, which will make it easy to adapt when I replace the Akai with a Nektar Pacer footswitch in the coming days.

Cheers!

-Jon

1 Like
2

What’s actually going on there is that the actual part number is calculated as

127 * (widget value / 100) to give you (in principle up to 128 parts or variations)

However, the next release (hopefully coming soon) will provide you with 24 directly selectable parts/variations through the system actions plugin, which should make it easier

3 Likes
3

I had a feeling that it might be the 127/100 thing. And the presentation of song part and variation numbers will be perfect.

The bottom line is that we can make it work today and that the System Actions in the Global Rackspace with the Widget paradigm is a great way of working! Very intuitive and powerful.

4

If you type “m” after a value, it will automatically calculate the midi 0-127 value range equivalent into the 0-100 range.

So you could type 3m for example in the widget value range.

3 Likes
5

Hmmm. It seems that SelectPartOrVar isn’t working quite right. It seems like these should be two separate controls, rather than Part and Variation grouped together.

I’ve got my sequencer playing into GP with a CC going to a widget that controls SelectPartOrVar. When I look at the Setlist page, the song part changes to the next part as expected and the associated rackspace (not sequential) changes as expected. But when I look at the wiring page, it increments to the next variation, rather that jumping to the rackspace associated with the song part. In short, my sounds don’t change as expected.

I can use NextSongPart, but that’s risky live when playing from a MIDI file. If the song part gets out of sync, it won’t recover unless I manually (pedually?) hit next/prev to sync up again. Sending a number just seems more secure than next/prev in that it can get you back in sync on the next change.

So, is this feature not quite ready for primetime, or am I missing something? I want to change the song part and have the rackspace follow as defined in the song.

For now, I’ll use next/prev. It’ll get the job done, and that’s what counts. :slight_smile:

6

When you’re in Wiring view you have exited setlist mode completely. The way most song/setlist actions work in GP is that you must be in Setlist view.

So there is no such thing as ‘looking at Wiring view’ while still expecting song/part actions to work (or so is my understanding).

1 Like
7

Okay, there’s something weird here. I made some global buttons for next and previous song part and hooked them up. Sure enough, when I’m in the Panels view, they don’t work. They work perfectly in the Setlist view.

Here’s the weird thing. When I’m playing MIDI into GP from Logic, and focused on the Setlist view in GP, the Next button changes the song part and the rack space changes properly. But when I press Back, visually, the reaction is correct and the previous song part and its rackspace are shown, but the sound is still from the second part. I go next/back/next and the visuals continue to change, but the sound does not. Next, I stop the MIDI playback, cycle next and back, and everything is normal again. So, for some reason, when MIDI is playing - even from an external source - the song part and rackspaces get out of sync - what you see in the GUI is not what you hear.

I exported the MIDI from Logic, played it from the MIDI File Player, and got the same problem. With MIDI playing, when I select Next, everything works great. When I press Prev, the GUI responds, but the sound change does not happen. When I stop the playback and do Next, Prev, it works properly.

I’m running a complex Gig right now. I’ll try a blank Gig and build the basics from scratch and see if I get the same result. Process of elimination.

8

I made a simpler Gig from scratch, and I believe that I’ve found the problem. It’s related to Rackspaces with MIDI persist enabled.

I’ve replicated the MIDI instrument(s) in the local rackspaces. If I enable MIDI persist, then the MIDI plays smoothly. Without it, notes get chopped off when switching rackspaces. I think what is happening is that as a MIDI note continues, it doesn’t let me change rackspaces when MIDI Persist is enabled and a note is sustaining.

I see a fundamental problem here. I could put all my synth sounds for MIDI playback into the Global Rackspace, but this would need to be for every song in the set. If I need to change songs for a new setlist, the required synths/samples could change. I’d need to load whole new Gigs per song.

I see two possibilities. One is to add an additional rackspace layer for songs. (Global + Song + Local(song part.) There would be no MIDI persist from one song to the next, so the change could happen smoothly and a whole new set instruments for MIDI playback could be loaded for the next song. Then, when changing song parts, amps and effects can change, but the MIDI instruments are stable.

Another possibility would be to handle MIDI persist kind of like predictive loading. It would work when going to the next song part, but not when going back or for random access.

It seems like I’ve reached a dead end with MIDI instrument playback while switching song parts, unless I’m missing something. (Given that keyboard players use this, I must be!) Anyway, time for a workaround!

Maybe I could use the Audio player globally for pre-rendered instruments. I could rely on MIDI playback for control and automation only. That would mean that I would need zero MIDI instruments for backing tracks. I’d only use them for live playing. (I play guitar and keyboards and plan to go back and forth on call and response stuff.)

And then there is the option of using something like Ableton Live in conjunction with GP.

I need to give this a noodle!

1 Like
9

Can you please upload the test gig where your issue can be seen? (rename it to txt if it doesn’t upload).

10

Doing the day job at the moment. I’ll do one better than this simple test. I’ll develop a gig that covers a related set of test cases. This will help users to know what to do and what to avoid and could help developers determine any issues - or note my user errors. :slight_smile:

Last night, I had an “aha” moment when writing in a related thread on the MIDI File Player. For a given song or continuous piece of music, I need to use a single rackspace and switch varations with the song part. Now it makes sense that SelectPartOrVar links parts and variations. We don’t rewire our equipment during a song. We just switch and fade things in and out; hence the variations.

I also rewatched Trey Gunn’s Intruder and Fishing Net videos and re-skimmed the Rosanna video. In each case, the songs use song parts and do not change rack spaces.

I might have been somewhat misled by the keyboard, guitar, and bass examples in the New Gig. They present different sounds in different rackspaces, so it implies that to go between Classic Bass and Distorted in a single song would be to switch rackspaces. But now it seems that switching instruments within a song is better done by variations by using widgets, mixers, controlling Note On, etc.

Anyway, I plan to provide a test gig and possibly a MIDI file to go through a set of test cases. I expect to complete it this evening.

11

TestCases_Rackspaces-and-song-parts.gig (400.3 KB)

Here is my test case gig. Go to the Setlists view, strum the guitar (input 2 - change in the global rackspace, if needed), play and hold keys, and use the Prev and Next keys. Try it for the various songs. Ionian, Lydian, and Mixolydian work fine. Dorian stops the keys, as we would expect…

In the “Phrygian” song, I can start on the first songpart, hold a key, press Next, and it works fine. But if you start on the second songpart, press and hold a key, and press Prev, the guitar sound gets stuck. This seems to be the bug I encountered earlier. Stop playing, hit Next then Prev and the guitar sound is again correct. Because my earlier test was with a constantly playing MIDI file, the guitar sound was mostly stuck with some random restorations when hitting Prev and Next many times.

In any case, I like expert mode. Having one rackspace per song and using variations within a song seems safest for live performances. It could be a bit heavier than necessary, but less likely to stutter when loading. Changing rackspaces between songs would ensure that any unexpected loading glitches happen (if at all) when not playing.

12

Quite the contrary - a major feature of Gig Performer is the ability to switch from one rackspace to another with zero glitching and that works beautifully well. I have one show piece I do where I rapidly move through about 18 rackspaces, with Patch Persist enabled as well.

13

That’s awesome!

Anyway check out the issue I found in this gig. Earlier, I found a similar issue when playing a MIDI file that set the song part with SelectPartOrVar. It’s possible that incrementing the song part (with next or SelectPartOrVar) works fine, but going back or out of sequence has issues when the song parts change rackspaces.

For now, I can meet my goals without changing rackspaces, so I can keep developing my setups without issues. (I could also just make more song parts and keep them sequential while changing rackspaces.) But after this Prev thing is sorted, being able to use rackspaces on the fly with random access and persistence will be really powerful and efficient for building new songs and sets. :slightly_smiling_face:

Looking forward to learning what’s up with my test gig…