There are similar topics but I can’t find an explanation to what is happening with my query.
I’m using a load of sounds in Global RS and I send the midi data from the Local RS via OSC blocks. All is fine and I can “sort of” get the midi patch persist to work but the problem is as follows.
If I sustain a string and change to another RS with exactly the same sound and midi block configuration, the string in the new rackspace carries on playing but sounds as if it were suddenly doubled. If I return to the previous RS the sound is correct and If I go back and forth it will do exactly the same. RS 1 : correct…RS 2 : doubled.
Is there an explanation for this and, more importantly, is there a solution?
I placed a midi monitor in GLOBAL just after the IN block recieving from LOCAL. I played 1 single note and maintained it pressed whilst changing to a new rackspace and I get the following :
Note On
(now I change RS)
CC64 Hold Pedal 0
(now I release note)
note off
The hold pedal register must be something internal in GP because I’m not touching the pedal
My first thought was that when I change rackspaces I were, somehow, sending a new NoteON message, thus the “double phasey” sound…but in the midi IN monitor, you can clearly see that the only messages received are those ;
The fact is that if the sound from the instrument in GLOBAL goes straight to the outputs of the audio interface, it works perfectly. The problem is that I send the audio to local for post processing and then back to GLOBAL for the OUTS
I do a similar type of routing, but without seeing screenshots I won’t be able to help much.
There are multiple native ways to route both midi and audio between the local and global rackspaces (via MIDI blocks, To/From Rackspace blocks, GP Relayer), and I’ve found that they all have slightly different behaviors in this type of routing scenario. If you’ve narrowed the issue down to one particular segment of the signal chain, I would suggest trying one of the other methods listed above to route the signal.
Ok, I think I see the signal path clearly enough.
What happens if you use GP Relayer to send audio back to the local rackspace instead of the To Rackspace block?
The only problem I see is that you are limited to 10 sends and receive. I’m luck I only use 8 (for now)
I’ve only tried it with the Pads Channel, which is the most important because it’s what I usually use to transition from one RS to another and maybe piano / Keys Affair… but, if at least the pads can do the transitions, that’s good enough for now.
This is true. If you end up needing more inputs/outputs, you can look into Blue Cat Connector. It provides the same functionality as GP Relayer, with many more ports to send/receive with. The catch is, its not free.
If it’s not free but does the job, that’s fine with me. As it is, I don’t have ANY pirate plugins or software in my machine… and it’s well worth the money spent.
Sorry, @edm11 … I was wrong. It seemed to work but it actually does the same as via ToLocalRackspace.
It seems to be doubling at some stage but I can’t explain why because in midi monitor in local and global, nothing extra is appearing each time I change RS.
if I switch to a new RS immediately after playing the last note in the previous RS and that instrument also exists in the new RS but in a different key range, it will play a single note of that sound EVERY time I switch.
It’s really annoying to have done so many changes so as to be more efficient just to find that in practice there are so many hicups and I have to revert back to using more RAM, longer loading time, etc etc..
I was using 27GB out of 32GB by working everything in local and now that I have placed the mostly used instruments in Global, I got ram usage down to 17GB and it works wonders because I’m using the exact same piano with its exact same eq EVERY TIME, same strings, same strings eq EVERY TIME and the whole gig file loads in 1m15s.
But because of the transition issues between RS it’s such an inconvenience.
On the other hand, I think about the fact that I can do pretty much everything I want with almost any sound in any song.
So, even with some inconvenience, I am grateful.
I can reproduce the ‘doubling’ effect you mentioned, using the routing example you’ve shown. It’s more like a surge in volume for me when switching between rackspaces, and then the volume returns to normal when switching back to the original rackspace.
Yes, it’s not only a surge in volume it’s like 2 notes playing at the same time. You can hear a phase-like effect at the same time that the volume spikes.
If only the patch persist function would work seamlessly, then GP would be absolutely perfectly perfect for me. I can’t complain, tbh, but it is annoying to find that, if you do things one way, you don’t get the benefits of doing things another way and vice the versa… There are always trade-offs one way or the other… It doesn’t 100% meet my needs ALTHOUGH I “sell” it to everyone in the business as completely flawless!
It’s an unusual routing because you’re starting and ending the signal chain in local rackspaces, whereas the more traditional routing would be Global > local > Global.
I understand why you want to design it the way you have, but I don’t see a way to remedy the issue with that particular routing. Patch Persist works fine with local rackspaces, but the interchange of routing between local and global back to local seems to be outside the scope of its functionality at the moment. You’ll have to eliminate that last route back to local rackspaces and send the audio directly to the Audio out block from the Global rackspace, I think.
I have song specific sounds in local, they are processed and sent to global. There, reverb is added and it goes to the global OUTs.
I also have INblocks in local that send to global instruments, the sounds comes into local to be processed and returned to global for reverb and OUT. So, really, the output is in global. Local is used as a starting point, processes audio and sends to global to the OUTPUTs.
Ok, I can’t see the specifics in your screenshots because the view is so wide with too much going on.
I suggest creating a new gig that displays the issue using GP plugins, making one simple signal path, with two rackspaces. Then you can upload the gig/take screenshots and share here. Then I can be sure that I am understanding things properly.
