My hardware synth goes through some global processing, then goes to the song rackspaces for song-specific effects, before coming back to the global rackspace for master processing. (I’m also using plugin synths, but they aren’t relevant to the issue)
The issue is that a couple of my rackspaces have midi persist enabled, and they continue processing the hardware synth even when I switch to a different rackspace. So I’m thinking of adding a gain plugin to each problem rackspace, with a widget that mutes the hardware synth when I deactivate that rackspace. Is this possible in GP essentials? Is there a better way of doing it?
I’ve been using GP for a few months now and never had a problem with MIDI patch persist until today. I think it’s because we changed the set order somehow?
What you’re describing actually sounds consistent with how MIDI Patch Persist works in Gig Performer.
When MIDI Patch Persist is enabled, the old rackspace doesn’t completely “let go” when you switch away from it. It keeps processing the held notes until the notes are released.
Your chain is: Hardware Synth → Global rackspace → (Song) Rackspace → Global rackspace
The persisted rackspace continues affecting that hardware synth signal even after you’ve moved to another rackspace.
Yes, I realize this is probably intended behaviour, although it seems to continue processing long after sound has stopped. Is there a way to add a widget that will mute within the rackspace when I switch away from the rackspace?
Another option: Does the audio input block continue to function on a deselected rackspace? I could simply duplicate my global processing to the local rackspace for songs that require patch persist.
If I may provide feedback on this feature, it seems to me that patch persist should allow note off messages, and continue processing audio, but disable note on messages and audio input to a deselected rackspace.
That block is relaying signal(s) from the Global rackspace, and as the manual states:
“…While MIDI Patch Persist will work with multiple plugins when switching between two (possibly complex) rackspaces, plugins in the Global rackspace, however, cannot participate in the patch persist mechanism.”
If you’re only sending audio signals from Global to local rackspaces, then MIDI Patch Persist isn’t going to do anything anyway. The Input Muting and Output Fading controls of each local rackspace handle the audio spillover from one local rackspace to another. You might experiment with some different routing schemes to accomplish what you’re looking to do.
Ok. It’s now working as I initially intended (with no changes), which has made me realize that I was actually experiencing a bug, and not a feature that I misunderstood.
Here is what I expected, based on my experience before I changed the order of the songs last week:
I play song A (rackspace A, patch persist enabled, includes audio processing of my hardware synth).
I play song B (rackspace B) Song B only has plugin synths, patch persist mutes rackspace A as soon as audio has stopped.
I play songs C, D, & E, all with their own rackspaces, patch persist varyingly enabled and disabled.
I play song F, which includes my hardware synth. Hardware synth should be processed by rackspace F and global rackspace only.
What actually happened yesterday, which I can’t recreate now, and have never experienced before:
I play song A.
I play songs B-E with no issue.
I play song F. Hardware synth is being processed by both rackspace A and F (as well as global). Extensive troubleshooting, muting and unmuting, nothing stops rackspace A from processing except disabling patch persist.
I get that blocks in the global rackspace can’t participate in patch persist, but the “from global rackspace” block is in the local rackspace, so I assumed it followed local rackspace rules.
It would be nice to have a “mute on rackspace deactivation” option on both the “from global rackspace” and “Audio in [interface]” blocks. It would be both a safety net against whatever I experienced yesterday, and could also address situations like the mic muting issue that was discussed last week.
I get exactly what issue you’re facing - I have experienced the same continuing audio throughput in long left rackspaces in the past. No, it could not be solved with the input muting and output fading controls.
My personal workaround has been the same ever since: a widget in each rackspace that mutes the from global audio input (using a gain block for up to two channels or a mixer block for more) when I leave the rackspace.
I have created an automated solution that only needs one global script which I’ve already described here somewhere. Will look for it when I’m at my PC,
Only one script in the global rackspace (less work):
In the global rackspace you need to add a short script that sets this widget to “mute” each time you leave a rackspace.
The important part is that the muting widget is always given the same handle, like MUTE.
var ew : ExternalWidget
On Rackspace(oldRackspaceIndex : integer, newRackspaceIndex : integer) // When we switch to a new rackspace we check
If BindExternalWidget(ew, "MUTE", GetRackspaceNameAtIndex(oldRackspaceIndex)) then // if the old rackspace included a widget with the handle "MUTE" and we
SetExternalWidgetValue(ew,1) // set it to mute
End
End
The reason that rackspace A is still processing is probably because at least one note still being held - note-on without a note-off or without a sustain-off CC, so this is probably a bug.
In that rackspace, are you doing any special MIDI processing, like a MIDI arpeggiator or customized filtered MIDI events?
I’m blocking note on messages but allowing note off messages for one synth. When I switch away my foot is on the sustain pedal, but patch persist should handle that just fine.
There’s a long reverb tail at the end of the song, is it possible that the reverb plugin (TAL reverb 2 VST3) is remaining active?
As you may guess, it belongs in the category “cannot be reproduced reliably”. Had I been able to reproduce the issue, I probably would have looked for a solution, not a workaround.
But since this workaround works so smoothly, I have never bothered to fix it since 2023 (GP4).
Predictive loading was off, that I know for sure.
But your little technical insight that even the audio input muting waits for a note-off which it may have never received is helpful, too, and could be a possible explanation!
Can you please try to temporary disable that reverb and see if the issue reproduces?
If the issue is not reproducing, then please try to set a reverb tail that fades out completely after few seconds and check again.
