Move Up Move Down by Script control


I want to do the equivalent of “move up” and “move down” within my gpscript.

Manual control-
I’ve set the gigperformer options to move up and move down and that works from my controller from song part to song part but it looks like another cc is needed to move from song to song. I would prefer to have the same cc to move through the song parts then into the next song. This is what the arrow key on the computer keyboard does. Can’t I do this from my midi controller?

GPscript control
I also would like to move up or move down within songs and song parts with the same up cc and down cc and not have to have a separate set of codes for song switch and song part switching.

How can I use the same cc for both song part switching and song switching (when you try to go beyond the last song part- it changes songs?

What GPscript function can send these codes?

A related question is why does “sendNow” use a midi In Block when you are sending not receiving? Is this to make it appear like a certain input device sent the code rather than the script?


Take a look at the screenshot, to switch to the next song with the same Midi Controller you have to uncheck the shown option.


This makes sense as you can manipulate incoming midi events from you controller and send to the
connected plugin.


Use this function:
SetSongPart(index : integer)
No need for sending CC Messages


I can see how the function name sendNow might cause some confusion. If You think of it as being called insertNow, would that help?

What’s actually happening is that GPScript is intercepting a message coming into a MidiIn block before it gets the default processing defined by parameters of the MidiIn block (that is what happens as a consequence of defining the callback) and then you optionally put a message back into the MidiIn block (or some other MidiIn block) so that it can send it on to whatever plugins to which it is connected.


Is the incoming midi intercepted before or after the global midi functions set in the options menu?


After. If a global MIDI function defines an event, that message will not show up in a MidiIn block.


I guess I have to read what the current song part is then increment or decrement. I hope This also goes from song to song and that going negative doesn’t create errors.


The function SongPartValue=GetCurrentSongPart(); seems to be returning the index of the song rather than the index of the song part. GP 3.0.43


Great catch — and great timing — we will be putting out an update later today so I just fixed this as well!


I would go for releaseNow, because the MIDI block callback catches in a way the incoming MIDI information which can then possibly be released after processing.

What was more confusing to me is the fact that a Program Change emitted from a MIDI block is ignored by GP. In fact GP is not after the MIDI block, the MIDI block is inside GP… if I understand well…


Except that is not how it works — for a start, the event that comes in might not be the same as what goes out - you might send in a note that is then transposed, delayed, used to trigger a chord, converted to a CC message, or multiple CC messages or a sysex message and so forth.

Secondly, while MIDI callbacks are triggered by specific MidiIn blocks, the message received (or created in the callback) can be sent to a different MidiIn block or to multiple MidiIn blocks. So the callback is not just an intercept.


Without any MIDI callback, the MIDI IN information simply goes out of the MIDI block.
If I “bind” a MIDI callback to a MIDI block the MIDI information is “caught” for being used within the callback function and won’t get out anymore until I do something.
What gets out of the callback function, is what I decide to release and eventually to redirect. I can release the original MIDI message or another MIDI message to the current MIDI block or somewhere else.
But, well, I understood you don’t like the releaseNow function name :stuck_out_tongue_winking_eye:


For so many reasons…