@Dave_bass5 Definitely check the default values of those widgets in each of the variations.
In the rackspace you uploaded, look at the dial widgets on lane 6. In each of the variations they are set to 0. If you map those dials to the Min Note, Max Note, and Transpose of one of the MIDI In blocks, and then switch variations, you’ll see that the dials all go to zero. You have to manually set the values in each variation for those values to be remembered— they wont carry over from the previous variation unless specifically told to do so.
OK - then you might want to use separate devices. Here’s why.
Let’s assume that your footswitch is a sustain pedal sending CC 7 (doesn’t matter if it is something else, the concept is the same).
Now suppose you want to layer piano and strings but you only want to sustain the piano. If you don’t use separate devices then you won’t be able to accomplish this as both plugins (piano and strings) will be receiving all the CC messages.
Now, you could just use your MIDI In OMNI blocks (separate ones for each synth) and then block the “sustain” event for the MIDI In block connected to the strings plugin. But that doesn’t easily generalize, particularly if you have a pedal that can send out all sorts of other MIDI messages because you’ll end up having to block a lot of those messages so that other plugins don’t directly respond to other MIDI messages. It’s just much easier to use individual MIDI In blocks.
I block the sustain on everything other than Organ and Piano. For Piano its sustaining, but for organ I use a midi filter so that the sustain pedal changes the Leslie speed, which is tied to the mod wheel and aftertouch (which I find easier to use for this).
The pedal is set up so one switch is sending out CC64, which is the one I use for sustain, the other two are used for Next/previous song part. Nothing else is getting sent.
Because I got this pedal about 2/3rd of the way in to creating my rackspaces I haven’t gone back and added a sustain block. it just works fine as it is so I don’t see the need, until I do of course.
It may not be the correct way of doing it, but it works as I want it to.
Maybe i just cant get my head around what’s happening but Im not convinced i always do this.
I know for fact that i have had key ranges or a transpose set and then reset when adding widgets (probably why i started this thread).
If it were that simple wouldn’t it always happen every time i added widgets?
Unfortunately, there really isn’t enough information to understand what might be going on here.
Here are some questiosn though -
it looks like you’re predefining a front panel and then (presumably) adding plugins afterwards. Are you always creating new plugins or are you duplicating existing ones?
In this Mercy song (for example), you have 6 sets of (implicitly) grouped widgets, each column has a transpose on it (among other things). When you switch variations, do you intend for the transpose (for example) to change? I suspect you don’t – and so I’m wondering why you haven’t configured “Ignore Variations” for those widgets?
You know as much as I do. The video shows what happened. I have no idea why it happened. I dont screen record everything when im using my Mac. when its happened its happend without me knowing until I notice it.
I sometimes duplicate a rackspace iii I know I’ll use the same plugins, other times I start afresh. I dont always use that Panel.
The Rackspace I uploaded is from a template with the widgets I might need in place. Sometimes I dont use any of the knobs, other times I’ll configure them as I feel I need to use those features. I dont always know what ill bet using when I start and its just a time saver.
I do use the Ignore variations as and when I need to, mostly with the Mixer levels. I dont use this with the knob widgets, if Im using them then they are there to change those parameters.
Everything works fine after its set up, it’s just the occasional hiccup when first assigning them.
One thing i never do (‘maybe i need to) when setting these up is adjust any settings on the Widgets other than assign them to a plugin and define the action.
I’m never 100% sure what I’ll be doing with them at the start. Obviously I’ll go back and change the settings if i need to, but i always leave them with everything else as default.
Well, at this point, I don’t think there’s anything more we can do at this point. We don’t have any other reports of this issue (which of course doesn’t prove anything) but until we can find a way to reproduce this issue, there’s nothing we can fix.
Let us know if you find a way to reproduce consistently.
I am not sure if I followed everything here. But, I ran into what sounds like a similar issue and resolved it.
I would explore whether that variation was inadvertantly saved with an incorrect setting.
Are you using setlist mode? Something that seems similar to this happened to me when I re-used a Rackspace Variation in a different song. Within the song part I had used snapshot (which I use all the time) to save the variation.
Then when I went to a different song without a saved variation, it used the prior setting.
So, I would explore whether that same variation was saved with the weird setting. And I would specifically check any song parts where you might have use “snapshot” to save a variation setting in the song part.
Thanks but no, I’m not re using any Rackspaces. Each rackspace is its own song, or at least the different sections of a song, and then i use these to make the songs up in Setlist mode.
I don’t use snapshots as such, if i alter anything in set list mode i use a button to send it to rackspace and update it.
The issue is only when i first assign the widgets, it doesn’t happen after that.
That really does sound like what happens when you have unassigned widgets with stock values in a rackspace with multiple variations, and then you assign those widgets to a block, and then change variations.
Your video was clear up until the point where you changed variations right before you showed the Transpose value going to -127. What we need to see is what the value of those widgets are in both variations before you assign them to the MIDI In block.
This is an example of what I am describing. I have 2 variations, and one unassigned widget. The widget is set to 0 in both variations(which is how it is when you first insert it).
I then assign that widget to the Transpose parameter of the MIDI In block. The dial widget moves to 5 (which the Transpose=0 value of the block).
When I switch variations, the widget moves to zero and the Transpose parameter goes to -127 because the widget in that variation hadn’t been assigned yet–it was still set to zero.
Maybe im wrong, but i assumed that you need to have widgets to have these changes in variations.
so for example, ill have a string sound with 0 transpose, and then need it at -12 or 12 in another variation. What I’ll do it assign a widget to the midi in block and give it a transpose function. Then maybe I’ll go to the variation that i need to change it in, and i guess at that point its gone to -127. Other times im in the variation that needs the changes and quite often that doesnt exhibit this issue.
I know for a fact ive had a transpose or note limit already set, and that has gone back to -127 etc. so its not only effecting new blocks with no adjustment in them yet. This is the irritating side as ill then need to work out where the key ranges were before they were reset.
I do see what you are saying though, and it makes sense if this is how GP works.
Yes, I tried that and I get the same as you are getting. I tried this with the Max and min notes widgets as well. Doing it in that order produces the issue every time.
When you perform step 4 above (Click on another variation - the knob will stay at 0) and then step 5 (Go back to the first variation), that second variation is remembering that the value of the widget is 0
So when you attach the Transpose parameter to the widget in the original variation (at which point the widget in that variation jumps to the correct value, representing zero transpose) and then you switch to the other variation, that variation, which remembered that the widget should be at zero, immediately switches the knob to zero which of course then sets the transpose to -127
In other words, every time you leave a variation, Gig Performer captures the current widget values so that it can reset them back when you return to that variation.
Ok, i understand that, thanks for explaining it, but why does it prioritise the widget and not honour the settings already in the midi in block in the other variation? It seems to involve more work getting things back to how they were.
So if what I described is precisely what you were experiencing, then this is very interesting.
The design in general is such that variations remember widget positions and widgets control parameters, not the other way around.
When you switch variations, the widget in the new variation is set to whatever value it had when you were last in that variation. It does not matter whether, at that point, the widget has been mapped to a parameter.
So when you go back to the first variation and now you map a parameter to a widget, the widget in that parameter will be set to the parameter value - that is a consequence of actually performing the mapping. But that new widget setting is not applied to other variations where the same widget value has already been remembered (because you visited that other variation before mapping the widget)
So this is where it gets interesting. As far as I’m aware, you are the first user in eight years to experience this issue and I think it’s happening because your design approach is not typical (which is not to say there’s anything wrong with it).
Most users will add their plugins to the wiring view, add widgets and then map them to plugin parameters before switching or indeed even creating other variations. In this situation, when you create a new variation, the widgets in that new variation will take on whatever values they had in the “old” variation, which is generally what is expected.
What I am now wondering is whether we should change the behavior in the following way.
If you have created multiple variations (and visited them) before you map a widget (or if you change the mapping), should we explicitly set the value of the widget to the plugin parameter in all variations at that point. This is something that we need to discuss.
Edit: I’m going to put this into our tracking system so that we can consider whether such a change would make sense for a future version.
I wanted to make a post about another issue, which I think might be similar, so ill post that here.
Ive got quite a few rackspaces where I use the B-3X, and have drawbar widgets assigned to the top drawbars.
I have a few rackspaces that when I go to use the Organ variation, all drawbars are in (closed), and I get no sound. I have to go in to the plug-in itself and click on the current preset, which resets the drawbars and widgets. I would assume this would be saved when I exit GP, as I always save on exit.
This in itself is a pain, as it happened live on Sat, but what I can’t understand is it doesn’t always happen, and ive used these backspaces many times without issue so its not like the widgets are set to be closed when I go to that variation.
Deleting the panel with the drawbar widgets in it fixes it permanently, but id really like to know why this could be happening.
Im aware this post doesn’t go in to detail and steep by step, and Its another one that I can’t purposely reproduce. In fact ive started to take out all the panels with drawbars to make sure I down get caught out again.
