I am new on GigPerformer after years of MainStage.
My first simple setup:
Pianoteq, Omnisphere for pad sounds and Originals for strings.
Everything works, except the OmniSphere sounds.
Are there special settings for the Midi or something?
Is your orange MIDI wire lighting up when you play on your keyboard? If so that means itâs sending the MIDI to Omnisphere. Might be a setting within Omnisphere you have to fix, check your MIDI setting in the Multi tab.
Your transpose is set to -127 in the MIDI In block. What happens when you set it to 0?
Thx edm11. this was the trick. I really donât know how the transpose was set to -127. But for now: it works!
1 Like
And later, it will still workđ
Ive found I still get the -127 transpose when I add a transpose widget in to a Rackspace sometimes. It still catches me out. Same with the min/max note widgets.
What type of widget have you assigned to the transpose ?
If itâs a button and itâs momentary - that could be the issue. Because when letting go it will send a value of 0 which represents -127
That will happen if you add a variation to a rackspace that has a widget not mapped to a plugin parameter, and then afterward you map that widget to a plugin parameter.
To use the example of the MIDI In block and the Transpose field: if an unmapped dial widget in the default variation has its position all the way to the left and then you create a new variation, that widget in that new variation has inherited that value of that widgetâ all the way to the left.
If you then map the Transpose parameter of the MIDI In block to that widget (in either the default variation or the new variation), the value of the widget in that variation changes to whatever is reported by the plugin blockâ in this case, the dial would move halfway and report a value of 0 semitones.
However, the value for the widget in the other variation had already been set , with its position all the way to the left. Which, in the case of transpose in a MIDI In block, means you get -127 semitones in that variation.
Itâs important to remember that when you create new variations from one that has widgets, the variation inherits the value of those widgets, regardless of whether they are mapped to anything or not.
2 Likes
Yeah, we have discussed this last year, I just thought id point it out to the OP in case this was the reason.
Itâs something to look out for.
1 Like
Iâll have to look at how that was implemented originally by Nebojsa. Offhand I canât think of a reason why he would have done it that way. If nobody else can think of a good reason, then it may be worth changing the behavior so that when you do new mapping to an existing widget, it always inherits the plugin parameter.
Thoughts?
I think the behavior makes sense.
To create a new variation that will in essence be a copy of the last selected variation.
Thatâs how it works. It seems totally logical to keep consistency.
To me it would not make sense the other way.
The issue in this case seems to be that the parameter is already set to -127 in an existing variation and so when creating a new variation it will inherit the same value.
Trying to think how/when the alternative would be useful rather than confusing.
Or how it would even work or make sense.
The problem thus seems to only have one scenario - when widgets are not already mapped and then creating new variations then mapping.
It makes sense to me the way it is currently, for a few reasons.
- When a widget is inserted, it doesnât have a null positional value, waiting for you to actually move the widget to have a value. It has a default positional value already, and that default varies with the type of widget you insert. e.g. for a Dial widget itâs all the way to the left, but for a Slider widget itâs halfway.
- A widget being mapped to something isnât required to change the positional value of that widget. i.e⌠You can change the positional value of the widget freely without it being mapped to anything.
- Since that widget has a positional value already, when you add a variation it naturally inherits the positional value of the variation it was created from. e.g. If Variation 1 has the dial widget set to the left, Variation 2 has the same dial widget set to halfway, and Variation 3 has the same dial widget set to the rightâWhen I go to create Variation 4, it will inherit the position of the widget based on whichever Variation is selected at the time I create it. Thatâs the only way that makes sense, since there are 3 other Variations, all having different values for the Dial widget.
So to me, I see widgets as always having a value. I see new variations as always inheriting widget values from the variation they were created from. That makes sense regardless of what they are mapped to.
Creating a conditional scenario for how widget values are assigned in other variations based on whether they are mapped to anything or not seems unnecessary and a little confusing.
My 2 bits.
1 Like
That would be my way of doing it. In fact i had assumed this was already by default, but then i learned otherwise in my thread about it last year.
I think itâs quite dangerous having the widget change whats already been set up. I appreciate we all work in different ways, but i cant see any reason to have -127 as a default action if you donât follow a certain way of setting your Rackspaces up. Sometimes i donât know what im going to need when creating a new song, but to have settings suddenly changed in a way that produces confusion seems not quite user friendly.
Maybe an option to have either way as a default?
We really try very hard not to have too many optionsâŚNebojsa used to refer to this as the BIAB problem 
I think weâre really discussing a difference in workflow.
Its clear that when things were designed, that it was assumed the workflow would be:
- Insert Plugins
- Add Widgets
- Assign to plugin parameters
- Create variations based off the need for the values of those plugin parameters to change
So when that workflow changes to:
- Add widgets
- Insert plugins
- Create variations
- Assign to plugin parameters
I can see why someone would be thinking the behavior should be different based on the latter workflow. However, even if I were to be emulating that workflow, what if I want to create 3 variations and purposefully pre-set the widgets to their values before assigning them to plugin parameters? If we changed the default behavior, then all those pre-set values would change the moment I assigned the widget to a plugin parameter.
Then I could be coming here and asking for the default behavior to change back to the way it was. 
I think its more important to emphasize and follow the designed architectural workflow. That pretty well goes for any audio application.
1 Like