This is not weird, it is working as designed 
What mistake?
@encore, Gig Performer has many ways to send a Program Change message to external hardware via its GUI.
The simplest one to test is to add a MIDI Out block to Wiring View for your iRig interface (if thatâs what the Juno is connected to). Within the MIDI Out window, there are options to send the PC message.
Alternatively, this same window includes a MIDI helper tool, where you can define multiple, specific messages to send, including sysex. IMO this is what you should try first - to test/confirm what message you need to send to the Juno to trigger a patch change.
Detailed instructions are here:
2 Likes
@encore, in my opinion, you should stop to think Juno as a reference when you are working with GP and rather think of GP as the place where thinks occur. You have a MIDI in port coming from the Juno, think of it as a âMIDI in from Junoâ (usually written âMIDI in (Juno)â) and not as a âJuno Out to To GP MIDI inâ, thatâs too confusing. Idem for âMIDI out (Juno)â, only think that it is where GP outputs MIDI messages for the Juno.
SendNow() is related to a GP MIDI in block, thatâs how it works. A GP MIDI in block is not a âcableâ or an âMIDI input portâ, it is much more, it is a GP proprietary plugin which can do many things like filtering incoming MIDI messages or produce itself MIDI messages even without scripting (see thee doc for this). And using GPScript and SendNow() or SendLater() it will emit MIDI messages produced in GPScripts.
Having said that, GPScript is very nice, but you should rather start taking the time to discover everything you can do with GP without scripting, this will help you to better understand the concepts of GP which will help⌠for scripting
3 Likes
hello @rank13
I was not sure that the MIDIOut block PC embeded support was adapted to my needs as I did not need to send PC when I select a RackSpace, a Variation , or a Song but rather from an action on Widgets therefore thatâs why I used the scripting solution as it was not clear to me how to trigger different PC changes based on a combination of interactions on different widget interaction. But I fully agree that as I am new to GP I am certainly not using the most appropriated method to do things as apparently there are several ways to achieve the same purpose.
But thanks a lot for the link and your suggestion , I ill check the documentation and the video tutorials.
Cheers, eric
hello @David-san ,
I fully agree with your comment regarding the naming I am using for the midi ports as they are quite confusing (even for me who choose the names 
) so I will fix this asap.
Nevertheless⌠I still do not understand why a Sendnow() method is using a MIDI block from where I am clearly RECEIVING MIDI messages FROM the connected hardware. Therefore to me it is not logical at all to SEND a message to a MidiXxxBlock object from where I am RECEIVING information from the outside of GP (so the data flow is wrong to me as it cannot work) while the SendNowExternal() function is logically expecting a MidiOutBlock arg and it is fully functional.
hmmmm⌠unless we are not talking about the same kind of MidiInBlock I see perhaps one usage of this SendNow(midiIn) function as it could be used perhaps in the Wiring view when a Scriptlet is sending modified MIDI data to another MIDI block or a plugin perhaps ?
But I fully agree that I am far to be a GP expert after one weekend of experimentation and I still have a LOT to learn . Thanks a lot anyway for your time and sharing your experience so it will save me time & efforts when creating my future GP panels & wiring.
I am wishing you an excellent end of day.
Cheers, Eric
The MIDI In block receives a MIDI message, as you noted and normally passed it on to whatever plugins are connected to its MIDI output.
However, if you use GP Script to process that message (e.g, by handling one of the MIDI Callbacks), perhaps so that you can change it, transpose it, turn it into a chord, etc then the original incoming message will not be sent out implicitly by the MIDI In block.
It is now up to your script to send out (or not) whatever messages you want to pass on to the connected plugins.
Again, a MIDI in block is conceptually neither a MIDI cable nor a MIDI in port, it is a GP proprietary plugin, which does much more. Open the MIDI in block plugin window to check everything it can do from incoming MIDI messages before it sends them out (or better, check the doc ).
So, a MIDI in block gets incoming MIDI messages from a MIDI in port, processes them and send them out. If you implement a GPScript MIDI event callback for a specific MIDI in block, it will bypass the regular MIDI messages flow for them to be processed in your GPScript. This means these messages wonât be sent out from the MIDI in block until you decide what should happen with them. If you want them, or if you want anything processed from them to go out of the MIDI in block, you will have to explicitly send them out of the MIDI in block using the dedicated function âSendNow()â.
Now imagine you have implemented a MIDI event callback taking its MIDI messages from a specific MIDI in block. You did some processing and want the result of this processing to be directed to you plugin instrument. Given that you donât think it is logical to send the processed MIDI information out of the MIDI in block from which you bypassed it for processing purposes, where would you reintroduce the processed MIDI messages for them to feed your plugin instrument? In other words, where should SendNow() send the processed MIDI messages? I am curious to know your proposal, but pretty sure it wonât be as simple as the current way it works. 
And by the way, SendNowExternal() is probably more confusing to me than SendNow(). Because, this is not viewable in the Wiring View. If you want to send something to an MIDI out block, I think it is often better to use SendNow() and to connect the related MIDI in block to the MIDI out block you need as this can be clearly identified, while doing this kind of connection within a GPScript make things more obscure especially when you forgot about what you did. No way to quickly check without reading the GPScript.
Hello @David-san ,
thanks a lot for your detailed answer.
I think I am too impatient of doing stuff with GP as it looks so simple to do your own things. But I realize now that as there are several ways of achieving the same things it could be easy to take a wrong path instead of a simpler one to do a task.
I think I should be more patient and (re)start from the beginning before starting to even build another GP Panel or RackSpace :
. read the doc
. watch more video tutorials
. load (and inspect) GIG created by other people doing the kind of stuff I need
. read more community topics related to my needs
âŚand only then (in a few month I am afraid ) I will be ready to create GP Rackspaces
Cheers, eric
Nice to see that youâve got your own plan. I am personally in the third phase of adapting my rackspaces and workflow to my need. I think you need to start without thinking of scripting and try to get the best from GP without scripting before doing anything else. Then donât try to build the ideal rackspaces, but only rackspaces for playing your music. With the time, you will know what you still need to improve your workflow, but take the time to use GP for playing music. You donât need months for that.
1 Like
When I started using GP, I created the first 30 rackspaces and gigs I needed in less than a week and was able to start playing on the seventh day (sounds like someone I know ).
But I do not know anything about scripting, that must be why I went too fast.
2 Likes