Controlling MIDI File Player through GPScript

MidiFilePlayer Auto Play Test.gig (385.2 KB)

I stripped it to bare bones for demo. Please try switching song parts and see if you can get it to play immediately. Thanks!

All 3 Songparts are referencing the same variation, right?
What should happen when you switch between the Song Parts?

Try this, I changed a little bit.
MidiFilePlayer Auto Play Test.gig (374.6 KB)

And now try this, each SongPart references the same variation and the Button is saved differently in the Song Part.
I do not see any issue
MidiFilePlayer Auto Play Test.gig (374.6 KB)

Are you on Mac?

What should happen, is when you click on teh song part, the midi file player should start playing. Does it do that for you?

Still not working for me. Of course I didn’t have your midi files so I put mine back in the MFP list. Here is the gig file back (deleted the scripts etc) and also sending my midi files, in case that’s where the “problem” lies. My midi files start immediately, no empty space at the beginning of file. That shouldn’t matter hopefully, as that is essential for starting the midi on 1 when I go to the song part.
MidiFilePlayer Auto Play Test2.gig (371.3 KB)

I was trying to upload my midi but its not allowing me to attach midi files…

MidiFilePlayer Auto Play Test.gig (374.6 KB)
1st songpart, midi is played
2nd sonpart, midi is stopped
3rd songpart, midi is played

Try this, I added an additional song at the beginning
MidiFilePlayer Auto Play Test2.gig (370.9 KB)

Still not playing automatically…

Wanted to update everyone. Apparently, the CC message being sent when switching song parts to change songs in the midi file player is getting in the way. Once I deleted that and changed song parts, the MFP started and stopped playing exactly as it was supposed to. So it seems the play command gets there before the song part changes.

I am using a virtual midi port to send the CC message to change songs in the player. I tried a couple of different ones, but same result. I suppose delaying the play command would do the trick, but that doesn’t seem ideal, since when playing with a backing track, the switch needs happen in synch with the beat. Unless the delay is so small its not detectable???

The simplest solution (for now anyway) is to midi control the play widget and send another CC message after the song selection CC message to turn on the widget. It works.

The issue is maybe simple to be solved.
Use the on Variation event to set the widget mapped to the Midi Play Button to the value 1.0
Maybe then the Midi Song is selecteded before you set the widget value.
Or you do not map a Widget and use the function to set the Play Parameter of the MIDI File player directly with scripting.

MIDPlayer.gig (77.5 KB)

Here is an example:

//$<AutoDeclare>
// DO NOT EDIT THIS SECTION MANUALLY
Var
   mFP : PluginBlock
//$</AutoDeclare>


// Called when you switch variations
On Variation(oldVariation : integer, newVariation : integer)
 if newVariation == 0 then
    SetParameter(mFP, 3, 1.0)
 elsif  newVariation == 1 then  
    SetParameter(mFP, 3, 0.0)
 elsif newVariation == 2 then
    SetParameter(mFP, 3, 1.0)
 end
End

@pianopaul This works very nicely when MFP is in the regular rackspace. Since I have mine in the global rackspace I would have to go with the variations setting the widget to 1 option I’m guessing. However, then every time I used that rackspace the MFP would turn on. I would only want this functionality when playing the songs in the setlist view. Looks like there is a “On Songpart…” in the setlist script editor that perhaps could be used in setlist view in a similar fashion? Am I correct, could that be adapted there to turn the widget on on songpart change?

I tried but couldn’t get it to work. There is one script editor for all the songs in the entire setlist, so can it be customized for individual songs in certain playlists? Of course at that point it may be easier to just send that extra midi CC in the songpart option itself??? If it could be limited to certain setlist, then I supposed I could create songs in that setlist where I would want the same rules (don’t play in songpart 1, but play in all others for example) and not have to customize it for each song. That would make sense!

Here, not directly related, a gig which shows how to map incoming CC message in the Global MIDI to switch down a rackspace or SongPart.
But the incoming CC message is not lost

The trick is to get the CC message and inject it into the new “Local GP Port”.
Now in Rig Manager you can learn an Alias to this message and assign it to whatever you want.
But as it is injected it is not lost in this example to get it from the MIDI In /IAC-Treeiber IAC-Bus 1)
Inject.gig (49.7 KB)

And here the code

//Called when a CC message is received
On ControlChangeEvent(m : ControlChangeMessage)
 InjectMidiEvent("Local GP Port", m)
End
1 Like

For my understanding, please help me process this. So you said “how to map incoming CC message in the Global Midi …” to do XYZ. The scriptlet is capturing and “injecting” this CC message to the “Local GP Port” correct? The scriptlet is connected to a virtual Midi In port. This is where I’m lost… the scriptlet is capturing the CC that is assigned to something already in the Global Midi Assignments? How? I see you put the MAC IAC virtual port in your case. Does that carry the CC used in the global midi assignment? I’m on windows. No matter what port I put there (virtual, or the actual physical which was used to assign the global midi assignment) none of them carries the CC message setup in the global midi assignment. As a matter of fact, that CC doesn’t even show up on my global midi monitor. What am I missing or misunderstand?

OK, the goal is to map an incoming CC message to the global MIDI but not loose that CC message.
For example when you map CC 64 the normal way to a widget, then you will have to do something to get that CC 64 for further processing.
With this scriptlet in the global rackspace you catch that for example CC64 and inject that into the new internal “GP internal Port” and use that for mapping a widget and at the same time you get CC64 from you normal MIDI input.

Hope I could explain :wink:

Oh I see! You are capturing CC that is not assigned to any global midi setting! Got it! This is brilliant! I see how the same CC can be used in multiple ways. However, it still can NOT be applied to any of the global midi settings after it is “learned” with the local port right? When I did that, I lost the association with the Local GP port.

When you use my gig and replace the midi in with your midi in then it should work.
When you go to midi learn in rig manager you should be prompted which device you want to learn from because now the cc comes from the original and from the internal gp port.

Why? What else do you want to do with it?

The goal for this example only :wink:
Without a given use case in mind, I just wanted to show the possibilities.

Here is an example: I have a PREV and NEXT global midi assignment for my IK pedal for variations/song parts. I want to use that same pedal to switch songs (so the usage stays the same), BUT use that CC in a script to delay the timing of the switch of the song parts to the next bar’s 1. Of course this is in theory only, not sure if its possible, since the same CC would be instructing GP to switch songs, as well as the script to not switch song parts until the 1. So thats a conflict. Obviously the way that would make sense, if that CC could be grabbed and manipulated (script) BEFORE it reaches its global assignment.

Or perhaps another example so that there is no conflict. I would want those pedals to be used as in the global midi assignment, except when I don’t need them for that and want to utilize the pedals for something else. Again, not sure if its possible… but at least it demonstrates a useful example I hope.