Controlling MIDI File Player through GPScript

Hi everybody,
I’m quite new to GP, and I cannot control the MiIDI File Player from within a GPScript.

  1. I made the MIDI Fille Player accessible through GPScript giving it the name Player

  2. I first tried to write a script at the song level with the following declaration at the beginning:
    var Player : Block
    When compiling the script I get the error that that type (Block) cannot be used in scripts at the song level, but only at the rackspace level

  3. So i wrote a rackspace script inserting the same declaration as before at the beginning; this time I get the erro that such declaration is not allowed…

So, how can I control the MIDI File Player through scripts?
What I would like to do is to change the midi file played by the player according to the active song part…

Thank you,

Luca

Hi Luca. The “type” to use is PluginBlock rather than just ‘Block’. I did notice that the online documentation doesn’t seem to mention PluginBlock ?

In rackspace scripts, once you’ve added your handles to any widgets or plugins, the easiest thing to do in the script editor is simply right-click and select the ‘Auto declare’ option. It will add all of those automatically for you.

However, the Song scripts don’t have direct access to the plugins in rackspaces. Is your MIDI file player in a local rackspace or the Global Rackspace?

Thank you rank13! yes, the online documentation does not mention the type PluginBlock :rage:

I would definitely suggest to GP develper team to upgrade the documentation, IMHO it’s not complete enough to let people using GPScript…

The problem now is that the callback Songpart is not accessible in rackspace scripts…

So I gues that I’ll have to insert my MIDI File Player in the Global Rackspace, am I right?

I tried but it seems that the Songpart callback can be overridden only within a script at the song level, but inside this kind of script I don’t have access to the PluginBlock… :roll_eyes:

I tried to insert the MIDI File Player into the global rackspace, but when I try to use its handle from within a script at the gig glevel, then I get the same error saying that this type (PluginBlock) is only accessible from within rackspace scripts…

I’m very frustarted because I cannot do even the most basic things :confounded:

Luca

That is only consequent, you have to build a song script.

or you build a variation for each song part and react in the onVariation callback in a rackspace script.
but remember, a variation could be used in a different song’s part.

you see, widgets are the robust approach.,

Yes but inside a song script I cannot use the handle to the MIDI File Player

Let us help you :wink:
You should not be frustrated, there is always a solution.
You can use widgets to control the MIDI FIle Player, and in SongParts you can override the state/value of the widget.
For example you use 1 variation for 2 SongParts then you can define different values for a widget in the differet song parts.
The trick is to save that individual value of a widget in the Song Part.
You find the disk symbol on the right side just below the list of horizontally Song Parts.
This way you can trigger actions with different outcome form the Widget Value because every song part can set such a widget to a different value.

That’s true, but that solution should not be a complicated workaround…
I mean, I simply would like to play different midi files depending on the particular song part that gets selected; it seems to me a very reasonable thing to do in a live performance…
Maybe it’s me who’s too stupid… :rofl:

And that is absolutely possible with widgets and map to the MIDI File Player

Ok, so I was right when I deduced that all must pass through widgets inserted into panels…
That’s exactly what I wanted to avoid; I simply wanted to use the callbacks Songpart to do all the stuff…
Anyway, thank you very much!
I’ll try the solution with the widget having two different values in two different song partes through the capture variation into song parte feature…

Here you see,
1 widget selects a song and with this value in the song part saved, when I switch the songpart the correct Midi Song is choosen

Why, Widgets are a very elegant way to show what is going on.
When you want to play a different Song in Part 1, just move the widget, save and you are ready to go.
Do you really want go into scripting for such easy things?

And with this Widget mapped to play, the Song is played from the beginning when you switch to the song part

MFP.gig (53.1 KB)

1 Like

or you build a variation for each song part and react in the onVariation callback in a rackspace script.
but remember, a variation could be used in a different song’s part.

you see, widgets are the robust approach.,

@Luca using the widgets and song part variations is always a good start. There are usually mutiple ways to achieve a similar outcome.

In this example, I am using my Mac’s virtual midi port to change songs (MFP is in the Global Rackspace).
Each song part has it’s own custom set of midi messages that it can send out when you switch to it. If I have a ‘Song Number’ widget in the Global Rackspace that is midi learned to my virtual midi port and CC, then this method will switch the songs in MFP.

MFP via Midi Loopback

When using song scripts, I have also successfully used OSC (sent just to your PC/laptop local port, so it’s picked up by GP) that can update parameters in any OSC-enabled plugin in a rackspace.

I’m trying to do exactly this. I set up a virtual midi port called Z-MidiFP-loopMIDI in “loopmidi”.
image
In the song part I set it to send CC out on that port:


I set up a widget that is controlled by the same port

Nothing happens. In the global midi monitor, no CC is being sent out upon song change.

In GP midi options, the port is activated

Why isn’t there communication? no CC’s being sent out by song part?

Can you upload the gig, maybe a smaller one, so I could check?

Have you checked it is showing up in the Global monitor if you just use the Midi Out block to send a message? So take the song part settings out of the equation.

Well, apparently windows needs to be restarted after adding a new virtual port. This am that’s all I did and it worked immediately. I feel like an idiot staying up so late trying to figure it out! LOL

Something odd happened at first though which I wasn’t even going to bother mentioning since it works now, but hey, maybe it does shed some light on something??? Anyway, after restarting the PC, I started GP and opened the global midi monitor. Almost as a cruel joke, an endless flow of CC55 (the very same one I couldn’t get going) was scrolling super fast in the midi monitor. Looked like something created a midi loop, but what?? Midiloop also mutes its port automatically even after a single midi mute and it did not. After about 30 seconds it just stopped and is working flawlessly since. WTH???

Can you upload a small gig showing the issue?
With virtual MIDI you have to take care, you could produce an endless loop very easily.
AVOID to USE MIDI In OMNI

1 Like

Yes I know. That’s the weird part, it was set to this virtual port and no midi loop… can’t reproduce and its working fine now, so not sure if we’ll ever know what happened. However, lesson learned, computer has to be restarted for OS (win) to use it.

This is what I’d like to do but its not starting for me. I would like the MFP to automatically start playing when I switch to the song part. I have the widget mapped in the regular rackspace to the MFP widget in the global rackspace. In the song part I put the widget ON and saved the song part to override the regular variation setting. When I switch to the song part, the light is ON but the MFP does not start playing. I think there is a delay when switching to the song part. If I hit the widget off and on again, it starts to play but not when you switch to the song part. Even after hitting it manually, there is a noticeable split second of delay before it starts to play. I’m guessing the command to “play” goes out before the player is activated???

OK, please build a small gig and upload, I will check.