create a file of midi messages which can be called by any button press on a controller.

On my fire controller, I key-down a button and load a variety of patches on all of my boards... all good, now on the same button 'key-up' I want to, ideally, call a txt file which has hundreds of SysEx messages which send feed back to the array of lights on the fire controller.. as feed back. Instead of creating these calls per button, can I just callin, linkto, automatically import... whatever term, a file with all of these messages? The end result will be key-down... set patches... key-up... light show on controller. In order to do what I want here I would also need to be able, within the 'file' to have delays of a few milliseconds to have the animated effect i'm looking for.


Fire - key down - patch changes

Key up... fire buttons flash and move around... ending up on the button that was pressed.


You can certainly send patch changes at key down as you already know. You can also use the key-up event for various outgoing actions. If you want specific timing of these Sysex messages, you will need to introduce delays at the appropriate point. How long are the Sysex messages.  Say you have ten 50 byte sysex messages you want to cycle through but you want to pause bettween message 4 and message 5.  You should probably create translators with each of the desired messages you want and then use a timer to set up the correct timing for them where you want delays.  Do you have an example maybe 5 or 6 messages you want to send in sequence along with the timing?

Another though would be to set up a DAW to send notes in specific sequence upon releasing a button (MIDI track) and then have the MIDI track call up the messages to be sent at timing you want.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist

Here is some actual messages i’ll need to send in order to change the leds under the buttons…
I’ve put *pause to indicate where I would want a short pause… just for show but is close to what I need to do so the leds will transition between stages for animation.
I would expect there to be about 20 times more messages than this but this is a sample. If I could create a file of these then call them from the translator when a key-up event occurs, that would be perfect as long as I can call that same file from other buttons. one reusable file basically.

F0 47 7F 43 65 00 04 00 7F 7F 7F F7
F0 47 7F 43 65 00 04 01 7F 00 7F F7
F0 47 7F 43 65 00 04 02 00 7F 7F F7
F0 47 7F 43 65 00 04 03 00 7F 00 F7
F0 47 7F 43 65 00 04 04 11 07 08 F7
F0 47 7F 43 65 00 04 05 20 33 55 F7
F0 47 7F 43 65 00 04 06 33 50 74 F7
F0 47 7F 43 65 00 04 07 50 2F 20 F7
F0 47 7F 43 65 00 04 08 40 1E 62 F7
F0 47 7F 43 65 00 04 09 7F 7F 7F F7
F0 47 7F 43 65 00 04 0A 3F 00 7F F7
F0 47 7F 43 65 00 04 0B 2A 7F 7F F7
F0 47 7F 43 65 00 04 0C 22 7F 00 F7

Hmm, OK I see a pattern here. Maybe the best way is to fill in the few byte differences using the pattern and the iteration through the differences.

For instance they all seem to start with the same header.


F0 47 7F 43 65 00 04

Then the next byte looks like a sequence number

Then the next 3 bytes are the actual data

Followed by an F7

So if we created a timer and used the pattern with just the 4 bytes that are different we could output a complete message

Header Pattern - pp qq rr ss F7

And then we used the sequence number pp to use set the values of qq, rr and ss. Then we could iterate through the messages.

For anything that needs a pause we would introduce a delay before the next iteration.

MT Pro does not "read" files, so the data would be imbedded in the translators, and we could use rules and if statements to call up the data we need. I'm sure the microKorg manual documents what the intent of these sequences unless this is bound for another device.

From a MT Pro structure standpoint we could call up sequences by timer names or pattern ID's etc. I'll look a bit further and give you an example of what I'm talking about tomorrow.

If you need truly to read from a file, then you will needs some sort of "helper" application to feed the data via MIDI to MT Pro, or to independently call to send the data upon the desired trigger. Something like SendSX or sendmidi which can be called up by program name and parameters.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist


Steve, you are correct… the pay load are the last 4 values. They are ‘pad location’ , ‘Red’, ‘Green’, ‘Blue’ values on the Fire controller. This is nothing to do with the MicroKorg. These messages, on the key-up event are ONLY going to the Akai Fire controller which has a 4 x 16 grid of pads on it… plus other pads, buttons and knobs. All backlit by RGB LEDs. So again, press a pad for a key-down event which will have translators sending patch change data to 5 keyboards and 2 modules… pad release (key-up) will do a quick light show on the pads of the Fire and end up highlighting the pad that was pressed. *On a side note and NOT a part of this thread… I’ll be pulling up a lyric sheet also, displaying tempo (clock) on some other pads, and the shuttle buttons on the Fire are connected to my DAW to kick off the backtracks. From the DAW i’ll be sending, at a certain time, a midi message which will be captured by a module I’ve designed which will control motors and external lights. (motors are for the robotic arm on the rig for soloing front stage. (yeah, get’n real ‘up in here’.) I’m sure i’ll have questions on some of that for another thread.

Well here is my first crack. I still haven't worked out the pauses though. Somehow I have to tell the timer to wait at specific messages before carrying out the next iteration.

The strategy is to start a repeating timer. The repeating timer sets the payload variables for each iteration and then starts a one shot timer to build the SysEx from there using the repeating variables.

Each message would be embedded in its own translator as rules and the timer "Send Message" can be generic sending messages as set by the various message builders.

The think I have not worked out is to ensure that there are no overlapping timers occurring that upset the order at timing of things.

I'm thinking maybe a repeating timer may not be a good idea or at least have a way to maintain a "wait state" while the next message is sent.


If this strategy does not work for you, we will need to think of looking at a possible helper application to send the messages that MT Pro calls.


Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist


This version should work better. Instead of a repeating timer, I use the last message sent to send off the next iteration with the appropriate delay. So essentially we have a timer re-triggering itself indirectly until the iteration count reaches 0.


Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist