Sending MIDI to Plugin via Script


Is there a way to send a MIDI message to an instrument VST plugin via a GPScript instead of connecting a MIDI In Block to the VST?

My use case is that I have plugins in several rackpaces that I have already attached an MIDI In Block (no problem so far). However I have an external MIDI controller that needs to send MIDI messages to the plugin (where the plugin does not have a parameter) as well. I don’t want to have to add new MIDI In Blocks for this other controller into all of the rackspaces.

The plugin right now in question is “Strike”. where you can send notes to start different drum patterns via notes but I’d like to set up my pedal to start and stop the drums which also uses a note message.

I know I could duplicate the blocks in all of my rackspaces but thought if possible I might be able to achieve this in a script that covers all rackspaces.

In the attached I have ONSONG already in the rackspaces and I would need to attach the MIDIBaby 3 as well in each rackspace. If this is the best practice then just let me know.

Again there are no plugin parameters for what I want to do, otherwise I would have mapped them and used a widget instead.



Take a look at the gpscript function SendNow()

SendNow requires a MidiIn Block


Indeed. Tried SendNow and it complained.


The short (and long) answer is no!

OK, thanks so for now I have two choices

  1. Create Input Blocks for each rackspace in Gig Performer
  2. Merge the input from my 2 different external MIDI ports into a virtual midi port outside of Gig Performer and tie the new single virtual input port to the Rig Manager Alias I created.

Thanks for the answer, though!


Why not?

Say you want to add a new MIDI controller (like a footswitch) that has a new function for the plugin.

Would you rather go to 50 rackspaces and add them one at a time or have a way to add the new controller once and and have it work with your existing rackspaces.

I think the concept is similar to what you did for Global Rackspaces which handle audio only and Rig Manager controls which can be tied to widgets. You do it once and then create an association.


This is a little ambiguous. A MIDI controller will typically be connected to a widget that does “something” and that something could be changing a parameter within a plugin in the rackspace you’re working with.

Do you have 50 racksapces where you have the same plugin and same control repeatedly used over and over again? If you do - could you please give us an example.


I think the only way to do it now in the Global Rackspace is to use the “To Rackspaces” and the “From Global Rackspace” plugins with “Global Parameter Assignment” linking to the widgets in the local rackspaces. And, that would still involve modifying each local rackspace.

Yes, I figured. No worries. Thanks!


Seems to be that the function you will want will be different in each rackspace (if not, put it in global!) but I’m not really quite sure why you couldn’t just create what’s needed in one rackspace and then just copy/paste the selection into other rackspaces.

It feels like you’re trying to solve a simple problem in a very complicated manner.

Yes, any time I have to do busy work, like lots of copy and pasting, I always wonder if there is something that can make it go faster.

I’m sure before global rackspaces were available, people were asking similar questions about hot to duplicate audio effect plugins across rackspaces without having to copy a lot of plugins.


I’m sure that us new people always bug you with stupid questions too. On the other hand I find that new people sometimes have the best ideas since they have not become complacent with how things currently work and may actually think of a possible better way.

Anyway, thanks for your patience!


Agreed – work flow improvements are always of interest (and the ability to copy/paste a selection was added in GP4 to make that process much faster). Favorites are also powerful here.

However, as I’ve noted in other threads, one must also consider whether a workflow is needed often enough to warrant a specific improvement and it is unclear to me how this specific use case is sufficiently general and required often enough to warrant special attention.

Sure – and it was also not possible to copy a selection so you had to do all the connections. But even with the global rackspace, it often makes more sense to paste stuff into individual rackspaces rather than overloading the global rackspace so efficient copy/paste is very valuable.

Well, probably not really often but like a different keyboard. If I go to a gig and have a different footswitch type (because the other one broke) , it would be nice to associate the new working footswitch for use with the various plugins. With that said, I probably can once I at least have one footswitch input block defined. So it is probably just a matter of how often you add new controllers that were not defined in the past.

Thanks again!


Sure. I routinely do this from the start for any instrument where I need it. Typically, I will define an alias called Sustain (say) and associate it with some controller through the Rig Manager (could be my current keyboard that has a sustain pedal or it could a separate pedal board with a sustain pedal).

Then I create a MIDI In block and give it the name Sustain. I check all the Event Block options except Sustain and then save the block as a preset or as a favorite (I’ve done both, depends on one’s needs)

I then configure my main MidiIn block (also aliased) so that Sustain is checked in Event blocking.’

Now – if I have to change the foot pedal device, I can just do it through the Rig Manager



@SteveC-Bome you know about this option when right-clicking a Midi In block? It then gives you the option to make that change across all rackspaces.

Yes of course, However this is a new MIDI IN block.


Perhaps if we could do a “replace all identical block across rackspaces” using a “favorite” as replacement and preserving the connections (which is probably only possible if they are identical) the problem would possibly be solved… :thinking: