It’s not really unbreakable, as you can always change which Rackspace and Variation a songpart refers to with a mouse click. And if you want to create an entirely new one just for that songpart, that’s also just a mouse click away.
If you don’t want Songs and Songparts to reference Rackspaces and Variations at all, what exactly to you propose in its place?
I don’t want song parts tied to rackspace variations. As detailed all over this thread, it creates nightmare issues of pedals changing what they do and inability to start on the correct part
Then just make a unique variation for every songpart.
There’s nothing wrong with having a unique variation for every songpart in your setlist if that’s what you want.
Or are you referring back to the “ignore songparts” request that I think was already resolved as well as it can currently be resolved in another thread?
This does not help the underlying problem. The problem is that the same midi message that selects the variation selects the song part
I don’t know it this helps, but……
In Global Midi Asssignments, you can select “Setlist” and (I think) you can set it to change songs and song parts without changing rackspaces/variations.
Also, I think you can use System Actions to change rackspaces and rackspace variations without changing song parts.
Yes, but only when you’re in rackspace or setlist mode respectively. If you are in setlist mode, the midi message only selects a song part. If you’re in rackspace mode, it only selects a variation.
It is not selecting a variation when you are in setlist mode (or if it is, then you’ve found an extremely serious bug)
Here is the issue. The message I use for choosing my clean sound cannot be separated from the message I send for song part 1, for instance in any way that I have found.
If every song starts from the clean sound fine, it’ll all work out great. But lets say a song starts with a distorted sound instead. Now, the pedal that chooses that sound has moved from pedal 2 to pedal 1.
Now, part of this is my fault for using Setlists for my song selector instead of rackspaces, but hopefully that topic has been done to death on how unfun it would be to fix a small change across hundreds of rackspaces instead of just one rackspace and having the songs based on them
Hopefully also, it won’t take much imagination to see what sort of carnage it would be in this case if one were to also use event based switching with the media player
I don’t see how this issue has to do with selecting variations vs song parts.
But it sounds like you want the same MIDI message to be used for different purposes - how is GP supposed to know automatically whether you mean “select song part 1” vs “select clean sound”?
If you want to do things like that (for example, if you are not in song part 1 then the message puts you in song part one but if you’re already in song part one, then the message should change a widget that controls clean sound) then GP Script is the way to do it (or even an extension) since it seems like you’re trying to fundamentally change the way that GP works in terms of handling incoming messages.
No I want to be able to use a different midi message for choosing variations than song parts.
I’m pretty sure we’ve been through this before.
In short you want to use Songs, but you don’t want to use Songparts as they are designed.
The concept of Songs and Songparts are designed around ideas like Intro, Pre-Verse, Verse, Chorus, etc. So when you start a Song you always want to be at the Intro.
That’s not what you want. You want your first footswitch to always be your Clean sound, your second to be your Breakup sound, etc. you want your Songs to start off in whatever tone the song starts in, and you want to move through them by choosing a tone rather than a “songpart” in the way GP intends.
As we covered in another thread, the only thing stopping you from achieving that is you need your Song to automatically jump to a particular Songpart instead of starting at part one. In your world Songpart 1 will always be a Clean variation, Songpart 2 a Breakup tone, Songpart 4 your lead tone, etc. Organizing your Songparts that way is no problem. The only problem is having your Song start out in the Songpart you need instead of always starting at Songpart 1.
The conclusion from the other thread was that A) you can do this with scripting (or an extension), and B) the developers said they would try making this possible in a future version without needing scripting.
I believe a pretty simple global rackspace script could do something like looking at the last character of your Song name, and when the song is entered the script switches to the Songpart specified. If you’re playing Back in Black and need it to start on your Dirty tone, which you always put on Songpart 2, you just call the song “Back in Black : 2” and the Gigscript instantly switches you to Songpart 2.
Then you have no problem with your midi or the pedalboard being in sync with GP. You just have to make your Songparts align with whatever place you want each of your tones to have.
I think you got it. And really, obviously, this is a first world problem in the very extreme. Gig Performer can already do everything I want it to do in this regard, my beef is with the time (and huge human error potential) of doing it the way things currently are. I really believe if we could have different MIDI commands for Song Parts than Rackspace Variations, that would fix things and I don’t yet see the downside of that case.
All that said, that new Song Selector/Part Selector/Stomp Selector extension may just remove this issue all the way anyway (except possibly in the case of using the event based switching system in the media player).
I think a safe thing would be to have a set of MIDI commands to pick song parts, a set of MIDI commands to pick rackspace variations and then the existing system of tying a song part to a particular rackspace variation. I know that could potentially make some trouble with event based switching, but I think if this is only a one way thing that can be mitigated
Doing that would be trivial with a Gigscript, but I think also pointless.
If you’re in Setlist mode your “change variation” commands will not work. At least not as far as I’m aware. And obviously if you’re not in Setlist mode commands to change songparts have no meaning.
I think the core challenge you’re having is that you are trying to: 1) force GP to operate in a manner that’s familiar to people accustomed to specific hardware systems, and 2) those approaches would work perfectly if you just used Rackspaces instead of Songs.
I get what you’re trying to do in this particular case, and it can be done. It just requires the user to ignore the concept of actual song parts, force them to assign a fixed set of tone-types to the songparts of every song (whether those tones are used in that song or not), and as a result force them to remember all their songs in terms of tones rather than parts.
I’m not sure how common that is, but the good news is you can do it either way. One just takes very slightly more work.
I think the extra “work” is loading a ggscript now, and probably without a gigscript in a future version.
Rackspace mode definitely works. I know there was one big issue I had with it but I think it got fixed in the last update. The time it costs is what I’m really hesitant of, but honestly, it is only as much time as it would take with most hardware, but man Setlist mode ends all that which is why I keep going back to it. I need to check if my main two issues with rackspace mode were fixed. Not sure if these song selector grid things will work with Rackspace mode, but I’ll check