MIDI in CC events causing unwanted behaviour

Gig Performer on Mac OS X
1

Hello - I discovered on my last gig that by leaving an iPad rested on my Nord Stage 3, some buttons were getting pressed which was disabling / switching off my Arturia plugins. I couldn’t troubleshoot this on the gig but managed to save things by reloading the gig file and moving my iPad elsewhere :slight_smile:

I found out at home that the drawbars were getting activated and messing with the levels on the Arturia plugins. So I decided to go through each of my rackspaces and for each Midi IN block, disable the other cc events messages - this seems to have done trick. However, is there a better or smarter method I could have used to achieve this? If not I will have to make a note to remember to do this for any future rackspaces I create.

thanks for your help!

Ranj

2

We are considering blocking other CC messages by default in a future update for precisely this reason. In 5e meantime for your future rackspaces, instead of just inserting MIDI In blocks directly, modify one to block other CC event and save it as a GP user Preset. Then going forward, insert that preset.

3

Thanks @dhj! I’ll do that for future.

Ranj

4

I’m not sure when the “Other CC events” option became enabled by default, but it literally cost me an entire day to track this down.

My older Gig Performer projects worked perfectly, while every new project I created suddenly had a broken hi-hat in Superior Drummer 3. Since the CC4 hi-hat controller was being blocked by default, it wasn’t obvious at all what was causing the problem.

I’m an e-drummer using multiple kits and different configurations, and MIDI CC messages are essential in this workflow. Blocking all other CC events by default can easily break e-drum functionality without any clear indication.

I think this behavior should be communicated much more clearly, for example with a tooltip, a warning, or a note in the release notes. It would save other e-drummers a lot of frustration and debugging time.

5

You say project, but you mean rackspace, right?

6

Sure, or better (for me). Project with several rackspaces.

7

Hmm, not sure how that change was left out of the release notes. It was indeed changed in 5.2.2. We’ve updated the release notes to include that information. This change was made because we saw many people wondering why the sounds of their synth plugins were changing when they “only moved a slider” and of course if you do not map an incoming MIDI message to a widget, it is automatically passed into plugins.

Right - the change only impacts newly created MIDI In plugins. All we can do is apologize that you had to waste some time figuring out what happened.

8

Thank you so much for this explanation.

9

You’re quite welcome and again, sorry that it caused you some grief.

10

In the current release notes this change is mentioned now

UPDATES

  • Song part actions can now switch to a different song or song part, giving you more control over the flow of your setlist.
  • If Gig Performer receives a message telling it to switch to the song part that is already active, that song part’s actions will no longer retrigger.
  • Hold Ctrl while navigating to a song part to bypass its attached actions. This is useful when you want to check a sound or adjust a level without triggering actions on that part. Actions from other sources are not affected.
  • Hold Shift to stop all pending actions, very useful if you accidentally create action in a songpart that causes the part to switch to another part (for example) thereby preventing you from selecting and editing that songpart.
  • Hold Shift while double-clicking on a Song Part to open the Action management window as well as the Song Part properties.
  • Touch support has been further refined.
  • The Other CC events option is now blocked by default in new MIDI In blocks.