I’m using the Strike 2 drum vst. It responds to a note #36 to stop the rhythm. After a nearly two weeks on a Win rebuild, GP now won’t stop the rhythm. I’ve tried the midi stop command and have also gone into the global midi settings and used the learn function. GP still won’t stop the rhythm. It seems to be a progressive thing in that the rhythm will stop fine when the computer build is new and GP is also a fresh install. Any thoughts on why this might be happening?
The “computer build” or “fresh install” should have zero impact on your setup. I can tell you that GP does not change anything as time progresses.
If this used to work and a note on 36 was working for that plugin - it must continue to work unless you changed something.
This change could be a simple fact that you may have assigned note #36 to a widget or a global control, you change how plugin responds to MIDI event etc…
Something must have changed - you simply have to find what it is.
Hey Al, sorry to hear that…
have you already checked in the MIDI monitor if there is a #36 coming in from your controller/keyboard (and on the right channel)?
Is it possible that 36 changes to 37 after some time has passed due to the fact that entropy is always increasing?
Or maybe a single bit just fell over?
Seriously: I also have Strike2 and i just tested it again and everything works fine!
Maybe the configuration of the MIDI-input block is not OK (i had to insert a second one, where i had to redirect the incoming notes from CH10/Keyboard to CH1/Strike-VST to make it work properly, see screenshot)
I checked the midi monitor Erik and note #36 is getting through ok. Yes the channel is fine as well. I’ve set everything up as you instructed me all those weeks ago.
I just don’t know what to do here. I seems every time I boot GP up some things are different. With the recent Win rebuild, I reinstalled GP and booted up my main GP gig. After that, I had to go through every rackspace (all 256 of them) and redo the desktop midi ins, otherwise midi messages will not be sent. If the messages are not sent, then the drums won’t start, fills won’t happen, strings and organs won’t come up to the required volume etc etc. Please remember I am a solo busker and need all this to happen for my act. So it’s not just the drums not stopping, but the whole show. I’ve been through and replaced the desktop midi ins now several times. If GP cannot change, and the Win 10 is a new build, what else could be wrecking my songs?. The only other thought I have is that the OnSong app sending the messages to GP over a dedicated wireless network is somehow corrupting them mid air.
This is indeed very odd. Question: you say you have 250 rackspaces. Are they all completely different or are many of them using exactly the same plugins?
All my rackspaces use Real Guitar and Strike 2 drum vst. The simplest rack uses two Real Guitars with different picking patterns panned left and right. Other racks may use a single RealGuitar with strings coming in at the chorus. The more complex rack spaces will use up to 6 RealGuitars perhaps 3 acoustic and 3 electric using a mix of picking and strumming. In addition Strike 2 drum vst will be in there as well plus organs switching from fast to slow rotary from verse to chorus. My iPad Pro in addition to controlling Gig Performer, also control a vocal harmony unit wirelessly using the Bome midi translator. My whole rig runs wirelessly including the PS3 guitar controller that runs Real Guitar in GP plus I use a wireless headset mic. So I have a lot of wireless stuff happening. Perhaps the wireless devices are causing compromises if that’s possible. But back to your question - yes many are using the same VSTs from rack space to rack space.
Well, I may have the answer. I tend to look at iPads as being basically bullet proof, so usually think the problem can’t be there. I use an app called OnSong, so I decided to back up the OnSong library and delete the app. I reinstalled OnSong on my iPad then imported the song library. Problem solved. GP stops fine now. I guess iPads are computers and need cleaning out and refreshing from time to time. I must remember to do it more often.
1 Like
Wow… glad to see that you found the gremlin! 
Thanks Erik. Not sure why the iPad got confused but pleased all is well.
I’m also obviously glad to know it wasn’t GP but I’d still like to understand what was going wrong and why?
Is there any sort of self analysis function within GP that might indicate problems?
Oher than the global midi monitor, there is nothing else. Not sure what there could be. GP essentially just responds to whatever is sent into it.
The midi monitor shows GP receiving the #36 stop command instantly. Is it possible that the free pc app rtpMidi which receives and passes the wireless midi messages on is somehow corrupting them and so not passing the complete message on? Is there a paid app to replace rtpMidi and maybe eliminate any corruption? My wireless network is generated by an Apple Airport Express which I always take with me. It’s set to transmit on 5.0 ghtz band to avoid the crowded 2.4 band. There are so many variables in my setup that could causes hitches.
Sorry to report the problem is back. I’m sure the problem is now in the iPad OnSong and the Bluetooth pedal I use to control the iPad. I’ll try the OnSong guys and see what they say.