This is a recurring issue for me and happened twice in a gig last night, causing LOUD stuck notes that do NOT respond to MIDI panic.
When switching songs (and thus rackspaces, as I typically use a custom rackspace per song), if I accidentally have the sustain pedal depressed when switching, the rackspace I’m switching FROM will get stuck MIDI notes. MIDI panic does NOTHING to resolve the issue, presumably because the stuck notes are from the previous rackspace. Most of my rackspaces use multiple MIDI input blocks and multiple VSTs to implement keyboard splits.
The stuck note problem can ONLY be resolved by loading up the previous song/rackspace, finding the EXACT notes that are stuck on the keyboard and playing them again (to get a proper MIDI off message to fire). I can switch rackspaces a hundred times, but as soon as I reload the offending rackspace, the stuck notes are there, playing loudly and proudly. Obviously, in a live scenario, this is bad news and is quite embarrassing.
The obvious fix would seem to be to instruct GP to send an all MIDI notes off message when switching rackspaces. Is this possible? Alternatively, sending a sustain OFF message when switching rackspaces might solve it.
MIDI panic seems to only panic on the current rackspace, which limits its effectiveness.
As of now, I can’t rely on GP for live gigs because of this issue and it’s a real bummer.
I just made a test case.
1st Rackspace Blue 3, patch persist enabled.
I played a note, pressed sustain pedal, released the note, the note continues playing because the sustain pedal is pressed.
Switched to 2nd rackspace while sustain pedal is pressed.
Sound can be heard - which is OK.
Then I released the sustain pedal, Note is stopped.
No hanging notes, I cannot reproduce.
Then I created 2 songs, each song references a separate rackspace.
I could not reproduce the issue with SetList Mode also.
Can you create a small gig where the issue is reproducable and upload it?
Could it be that the sustain pedal is affected to something else in the next song, such that the sustain cannot be stopped anymore in the previous song?
This is the EXACT same issue I have been having. Leaving a backspace or variation and retuning to it only to find stuck notes that are ringing. I think that GP is not sending the note off message in some cases as it is supposed to. Previously, it was suggested that certain plugins weren’t responding properly. But I have noticed that it is happening with several plugins, several of which I did not exhibit this behavior previously.
I do have patch persist on and will try turning it off to see if it makes any difference.
@rmirabelle@amor We really need a reproducible case. It is impossible for anyone to even try to figure out why is a particular problem happening unless they can reproduce it.
While I’m not excluding anything - I would personally be astonished if this was something within GP. If this kind of an issue was there - everyone would be seeing it a LOT.
More likely - this could be a problem where either there is something is wrong within a plugin (we’ve recently discovered some cases) or something else is going on.
For example - a script could be filtering note on and off messages in an unpredictable or simply erroneous way.
So PLEASE try to give us a reproducible case/steps and I’m sure we’ll figure it out.
Patch Persist is disabled on all rackspaces - I’ve never used that functionality.
I use a Roland RD64 keyboard with sustain pedal plugged in.
I’m using a Korg Nano controller for song and song part switching (having assigned buttons for next/previous song/song part respectively).
For most of my rackspaces, I implement splits by using multiple MIDI input modules, each connected to a separate VST. For instance, I’ll have MIDI input 1 routed to a Keyscape piano, where the MIDI input filters to keyrange C4-C6 and I’ll have MIDI input 2 routed to a Kontakt bass, where it’s MIDI input is filtered to keyrange C1-B3, etc.
I frequently use the extended settings on a MIDI input module, such as filtering to receive on a single Source MIDI channel only, such as channel 1. And sometimes I will use Event blocking on the MIDI input to filter out receiving ModWheel or even NoteOn or NoteOff messages.
I have a feeling that it’s some combination of settings in the various MIDI inputs that are causing the stuck notes problem. For example, if I switch from a rackspace with a single MIDI input with no filters or custom channel mappings to another rackspace with multiple MIDI inputs with some combination of custom keyrange, channel mappings or event blocking.
I understand that without patch persist enabled, note/sustain off messages should be automatically transmitted whenever I change rackspaces, but I wonder if the configuration of the MIDI inputs on the rackspace I’m switching TO might somehow be interfering.
So far (and rather unfortunately) the only time I’ve encountered this bug is during live performance, where I don’t have the time to debug. If I’m fortunate enough to experience stuck notes during a practice, I’ll stop what I’m doing and grab the complete configuration of both the ‘from’ and ‘to’ rackspaces.
Thanks @rmirabelle - I know it’s obviously not easy to reproduce this.
As a side note … it’s VERY easy to generate stuck notes if someone wants them
Simply filter the NoteOff messages in the MIDI in block and every note will be stuck.
Just a theory… could there be a VST3 peculiarity here?
My understanding of VST3’s is that they attempt to save CPU by halting themselves when not playing. Possible that when a rackspace is switched a slightly buggy VST3 determines that it’s no longer active so it halts itself in whatever state it was in. If the note off comes in after it’s suspended itself it doesn’t hear it.
Then when you switch back to the rackspace it goes active again, picking up in its prior state. If it was sounding a note before, then it continues sounding that note until it gets another note-off on the same note.
I suppose that’s possible. I generally prefer VST3’s in my rackspaces. While VST3 supports suspension of the process if no audio is being received, I doubt most plugins will do this automatically, without regard to the host configuration. For example suspending VST3’s is an option that must be enabled in Cubase.
Interesting…I don’t think I’ve disabled note off messages for any of the MIDI inputs. It IS possible that I’ve disabled note off messages on a single MIDI input mapped to a single MIDI channel (e.g. MIDI input #3 mapped to MIDI channel 10), but the sustained notes were originally triggered on channel 1, so you wouldn’t think there would be any overlap.
I used to prefer VST3’s myself, for the same general reason.
But then I ran into enough weird behaviors that I tried going back to VST2’s, and when I did my weird behaviors vanished.
I don’t remember exactly what all those weird behaviors were because I was just starting with GP at the time and certainly a lot of user ignorance was involved. I remember one of them was Gig file growth. I looked into it enough to manually edit the Gig files and see that for some particular VST the state data just kept growing.
I had some weirdness with sounds starting up again when I switched back to a rack that I had left previously, which might be the same thing you’re talking about. I just don’t remember it very well. I haven’t had the issue again since I went to VST2’s, but I’ve also greatly reduced the complexity of my rackspaces since then as well. (I stopped trying to do “clever” things to improve efficiency, focused on usability, and my experience vastly improved.)
@djogon Yes, I understand. But I still have not been able to identify a succinct sequence of events that create/recreate the problem. But rmirabelle’s description so perfectly described what I have experience that I had to chime in to say that it mirrors my own.
I had one rackspace that was exhibiting this behavior in several variations and so I thought I had found a good rackspace to submit. But when I returned to it the next day, it was no longer happening. Will definitely check back when I have something reproducible.
There’s a reason developers say premature optimization is the root of all evil