Enhanced Patch Persist?

Appreciate your explanation David. I’m right in the middle of streamlining my rig.
As with any of these things I need some time to figure out the best way of doing it and yes! no doubt i’ve got used to working a certain way and maybe I can get used to working with patch persist as it is!

If I do knock the A50 out of the equation I guess I’m going to have to use multiple scenarios of the rackspace each with the sounds preselected for each part of the song. I don’t actually own a dual footswitch to midi box yet so just to send CC data to the rackspace I’ve assigned two of the panel switches on an A50 patch to act as rackspace up and down toggles. Obviously before I am able to use the multi duplicated rackspaces to cover each sound change in a song I’ll need to alter each ones plugin patches: the quickest way of setting each one up is to have the old patch changes sent from the A-50 for each part in the song, saving each rackspace as I go. I’ll then disengage the A50 just using its panel switches for sending the two CC messages to toggle the rackspaces up and down. (I actually rarely have to go backwards in my programs!) I’ll see how I go and report back!
As ever, thanks for all your diligent input on this!

I’ll also get clued up on GP Setlist and Song part as I may well be missing a trick here too!

…OK I have now got to grips with Song parts/Setlist and set up a preliminary 5 song parts each utilising 5 respective rackspaces to harness the patch persist feature. What has occured to me is that it seems a pity the patch persist feature is not directly available in Song parts as one can assign a program change to be sent out with each song part that I am currently using to change the Setlist window in my Kronos. It just seems a little convoluted to have to harness a separate rackspace for each song part simply becasue it is the rackspace that only has the patch persit feature when in actual fact it is the song part that sends out that vital patch change I need to my Kronos SetList. (I will of course have to set up the missing patches that my A-50 was sending out too to hardware vocal effects and other things in my rig somehow.) Am I missing something here?

P.S. I would still like to have the option to use my “lazy timeing” of the actual change and perhaps a slightly altered script could allow me to have this? However for now I’m more concerned with having to harness separate rackspaces because the actual patch change is much slower than when using one rackspace for all song parts. Afterall all I am wanting to do is change sounds/volume levels within the same rackspace. Ideally it would be much better to be able to delay the program change send out from the song part via sutain pedal/held keys.

I am sorry, I have not read everything in this post with care, but have you explored plug-in persist? See below:

Yes! am well aware of the Plugin Persist script however it’s not relevant as I’m not bypassing any plugins: merely selecting ones to use from my master keyboard who’s master patch change is being automated by the Song parts/Rackspaces with Patch Persist in tow.

1 Like

I realise now that the patch persist feature is not what I’m looking for as it is indeed the delayed actual patch change I need as I have described. The whole point of keeping ones hands on the keys or holding the current sound with the sustain pedal is to time that patch change with ease with a natural release of ones hands or the sustain pedal as one does to play the first beat of a new musical passage. The problem is that my whole rigs patches will still change regardless of if keys or sustain pedal are held down because with patch persist it is only the notes that are held. When I say my whole rig I’m talking about vocal reverb/delay tails from a TCHelicon VoiceLive2, any hardware sequencing patterns I have going on, hardware synths etc etc. With the Roland A-50 I can at least hold off the actual patch change right up to the natural moment when I lift my hands off the keys/sustain pedal. You can’t do this with patch persist unfortuntely. Hence I am still looking for a way to do this without my A-50! …although pianopaul’s script might be the remedy!..

Hi pianopaul! Can you please tell me where I actually put this script of yours in GP?
Forgive me! this is the first time of using GP Scripting! I have opened GP Script to paste your script but I’m a little confused about where /how to place each script for Midi In Device and Rackspace respectfully.
Thanks!
P.S. I will read the threads on scripting that I’ve just found too!

Open this window for the gig script

Open this window for the rackspace script

For this gig script change the number 24 to the CC number your controller is sending to change the rackspace

In Rig Manager create a MIDI Device Alias and use that name in the script below

var TW : MidiInDevice

On ControlChangeEvent(m : ControlChangeMessage) matching 24 from TW
 SetEnvVariable("CHANGE", "DO")
End

Thanks pianopaul!
I’ve pasted your scrips in their respective script editors and pated an alias midi device name into the gig script but whenever I hit compile I get these errors!..

How looks your Rig Manager Window?
Did you name it TW?
When not, use your name in the script.

Did you give a Handle to your MIDI In Block?

Typo : hdevice => MidiInDevice

Menu Entry “Set Handle…”
Give a name and check “Use in GPScript”

1 Like

In terms of the error on the left, you have the parameters the wrong way around

screenshot_345

Guys! generally I’m a little lost at sea with this scripting!.. I’ve never used the Rig Manager window before now. The screenshot I posted is what I currently have after pianopauls kind instructions!

As far as setting the handle is concerned do I simply type hdevice which is the alias I added in the Rig Manager?

Hi David, what should I actually type to replace this line then?
Then there’s the error in the other script too!.. all rather confusing!

If we can get this sustain pedal/program change thing working I’m positive it will be of benefit to a lot of other live performers

Can you post a screenshot of your Rig Manager Window?

The other way around means that instead of

SendNow(m, MIN)

you should write

SendNow(MIN, m)


Midi learn the hdevice alias with your controller
And in the gig script replace TW by hdevice

And: read the manual :wink:

Thanks for the link! I’ll certainly watch that and continue reading the manual!

…I’ll muddle my way through this somehow and get back here to repost hopefully with some positive results!
Thanks to you both!

…Isa this correct?