Request Names of all 5 Rigs in current Performance via SYSEX

JanosB · January 1, 2017 at 11:49 PM

Hi,

I'm developing my own Profiler Remote from scratch. I want it to have 5 little color-displays placed over 5 Footswitches to select the 5 rigs from the current Performance. Each display should show the name of the Rig and should be colored from blue to red depending on the gain of the Rig.

For that I need the controller numbers to create the SYSEX that requests these parameters. I don't find anything about that in the MIDI Parameter Documentation, until now I only found out how to request the name of the active Rig. Before I try out every possible value, can anyone help me with that? Is there an even more detailed list of all controller/parameter numbers that can be requested than the MIDI Parameter Documentation pdf or has anyone done something similar before?

JanosB · January 3, 2017 at 9:23 AM

Okay, as nobody seemed to know anything about that, I took the "hard" way, wrote some lines of C++ Code that sent out every possible SYSEX String Request and wrote the response to a file if there was any. The list generated this way is by far shorter than I expected it to be. I attached it to this post, maybe someone else has a use for that. Seems to me as if I can't request the Information I wanted to get this way

JanosB · January 3, 2017 at 12:36 PM

After continuing to search for a solution, google gave me this post: DIY Pedal board for kemper, I hadn't seen before. This seems to solve my question - I have to send an extended string request . In the other thread, the corresponding 32-Bit Controller Numbes for the slot names are given, so this gives me everything I wanted to get, but anyhow, a list of all possible Controller Numbers and their meanings would be great. Is such a list available? Or should I do a second run with my test code and now poll every possible extended string request (which could take quite a lot of time with 2^32 possible Controller Numbers )?

slateboy · January 3, 2017 at 6:49 PM

can you show a few examples of what sysex message you send and the sysex message it returns, please?
How are you breaking down the returned sysex into a "usuable" string?

JanosB · January 6, 2017 at 11:17 PM

Today, I implemented the extended string request with the 32-Bit Controller Number and managed to get the slot names. I'll go on and send some systematic extended string request sequences over the next nights and see if there are any interesting results.

Quote from slateboy

can you show a few examples of what sysex message you send and the sysex message it returns, please?
How are you breaking down the returned sysex into a "usuable" string?

I don't know if you have any experience in C++ programming?

I'm developing the application on my Mac, for that I'm currently developing my own C++ CoreMidi Wrapper - you can find it here and design it around that. Now, if an incoming sysex message arrives, it gets copied into a dedicated byte array and a callback function is called to process the syses Buffer, it basically looks at the 7. byte, the sysex function code and decides how to handle that sysex. In the code snippet below, it simply casts the fields containing the ascii characters of the returned string to char and copies them to a char buffer which can be handled as a standard C-string. That's it

C

#define SYSEX_FC_STRING_PARAMETER 0x03
#define SYSEX_FC_EXTENDED_STRING_PARAMETER_CHANGE 0x07
switch (sysExBuffer[6]) {
        case SYSEX_FC_STRING_PARAMETER:
            if(waitingForSysExString){
                uint32_t  stringLength=sysExLength-11;
                if(stringLength<=sysExStringBufferSize){
                    uint32_t i;
                    for(i=0; i<stringLength; i++){
                        sysExStringBuffer[i]=(char)sysExBuffer[i+10];
                    }
                    sysExStringBufferSizeError=false;
                    receivedSysExString=true;
                }
                else{
                    sysExStringBufferSizeError=true;
                    receivedSysExString=true;
                }
            }
            break;
        case SYSEX_FC_EXTENDED_STRING_PARAMETER_CHANGE:
            if(waitingForSysExString){
                uint32_t  stringLength=sysExLength-14;
                if(stringLength<=sysExStringBufferSize){
                    uint32_t i;
                    for(i=0; i<stringLength; i++){
                        sysExStringBuffer[i]=(char)sysExBuffer[i+13];
                    }
                    sysExStringBufferSizeError=false;
                    receivedSysExString=true;
                }
                else{
                    sysExStringBufferSizeError=true;
                    receivedSysExString=true;
                }
            }
            break;

Display More

If I monitor the MIDI-Data with "MIDI Monitor", a helpful tool for MIDI debugging, while requesting the slot names, it shows me all the messages to and from the amp needed for that:
sysex_log.pdf

Anyway, the my programs string output is a bit better readable It just checks sequentially for sysex string responses on extended string requests over a given 32 Bit Controller Nr range.

Code

Connected to device UM-2
success for Controller Nr 16383: MIDI Controller
success for Controller Nr 16384: MIDI Tests
success for Controller Nr 16385: Rig 1
success for Controller Nr 16386: Rig 2
success for Controller Nr 16387: Rig 3
success for Controller Nr 16388: Rig 4
success for Controller Nr 16389: Rig 5

slateboy · January 7, 2017 at 1:40 AM

Thanks for the info. Looks like some heavy going there!
I've only fiddled a bit with C in an arduino environment (or is that C++?) and built a couple of midi controllers with it, sending control data and sysex.
Not yet delved into receiving and processing sysex, which is a forthcoming project, so interesting to see how others are dong it.

JanosB · January 7, 2017 at 9:16 AM

The arduino environment is a great starting point to learn programming! The Arduino framework is written in C++, but as C is a subset of C++, most code lines you see in a usual Arduino sketch are pure C Code.

Did you use the MIDI library by fortySevenEffects for your arduino project? If you didn't, take a look at it. It allows you to attach callback functions for all kinds of incomming MIDI data, which are called automatically if MIDI Data is comming in. You could basically just copy & paste the code above (just remove all the error checking for a first run) into a sysex callback function and do a serial.println(sysExStringBuffer) at the end to see if it works.

slateboy · January 8, 2017 at 12:37 PM

I've not used the midi library. Wrote code from scratch to help me understand the arduino system as its relatively new to me. Also allows me to implement exactly what I require.
Will be having a play with that sysex receive code over the coming weeks.

Gizmo · March 14, 2018 at 10:01 PM

Hi guys.
Having a great deal of trouble getting the SLOT names via Sysex.

I can pull out say the active rig name with this standard string parameter request....

0xF0, 0x00, 0x20, 0x33, 0x02, 0x7F, 0x43, 0x00, 0x00, 0x01, 0xf7

But trying the extended request to get the SLOT names I have used both the sequences below with no success. Below examples are using parameter 0x4001 encoded in 5 bytes to get SLOT #1 name

0xF0, 0x00, 0x20, 0x33, 0x02, 0x7F, 0x47, 0x00, 0x0, 0x00, 0x01, 0x00, 0x01, 0xF7
0xF0, 0x00, 0x20, 0x33, 0x00, 0x00, 0x47, 0x00, 0x0, 0x00, 0x01, 0x00, 0x01, 0xF7

I had no real hope that the last one would work as it doesn't use the Kemper manufacturer header, but I saw that someone here seemed to make it work.

First question..
I'm using 0x4001 to 0x4005 for slot names 1-5....are these correct? and where the heck did I get them from anyway!!! Can't find them at all in the KPA MIDI doc v1.5

Second Question
What's wrong with the first of my two extended requests???

Thanks for any and all help.

Gizmo · March 14, 2018 at 11:52 PM

I'm an idiot...
I had an index to count and send the bytes and hadn't updated it to send the longer sysex stream.
Problem solved.
Geesh. 2hrs to find my stupid error!
Call me Brain dead

Gizmo · March 17, 2018 at 8:20 PM

So this is a real question…not one created by my inability to spot my own error…at least I hope so;-)
OK, does so anyone know how to get the KPA to tell me what performance and slot is currently selected using a sysex parameter request or other means.

Here’s why I need it.

On stage I use a home made board with enough buttons just to change 4 stomps and select my slot (using left right only).
I’m displaying the current stomps state (on/off), current slot name, and current slot number on my board. I interrogate the KPA about every half second to keep my display updated with stomp status and slot name.

Here’s the problem…..If I want to change to a different performance, I do this manually at the KPA and sometimes change the slot as well.
My pedal doesn’t know that I’ve changed either slot or performance because I did it using the KPA buttons , so I’d like to get that info through interrogating the KPA from my pedal to keep things in synch.

The KPA manual says on page 5."With firmware 2.3.0, the profiler, if in performance mode, will send back the current performance number via CC47 and the appropriate slot selection. “

Nothing I do can can result in this kind of response.

So, anyone know how to get the KPA to tell me the current performance and current slot number..please?

slateboy · March 17, 2018 at 9:44 PM

I think the slot and performance name will only be sent over sysex if "called for" but not on slot/performance change otherwise there would be excessive/unwanted midi traffic. ( i might be wrong but this is how I understand it)
In which case youd need to "poll" the kpa at regular intervals to scan for changes. Obviously sending a "change" instruction from your device would be followed by a request for the name data that could then be processed accordingly. But changing the kpa locally would miss this. You could compare the current data in your device with that in the kpa and if different request the complete data required.
Does that make sense?

Gizmo · March 17, 2018 at 10:03 PM

Thanks Slateboy, yes, I do realize that changing the KPA locally doesn't automatically send anything, and I'm not after the current performance name, just the number, plus the current slot number.

I already get the slot names by polling the KPA via sysex, and I could get the performance name too (which I don't really need)

However I don't want to have to continually poll for and compare strings unless I have to and I can't see why I am unable to get just the numbers....which are easier and quicker to get and compare.

So if I make any change to the KPA performance or slot locally, through polling I can easily keep the pedal up to date.

slateboy · March 17, 2018 at 10:34 PM

I think a simple performance change can issue a midi program change, even when done locally at the kpa. Midi Prog number Needs assigning in the slot of that performance. Would that be enough to give you what you need?

Gizmo · March 17, 2018 at 10:52 PM

yeah, that might work but it would have to be done on every slot in every performance I use, plus I think each one would have to be different. Not what I'm prepared to do really.....it seems daft that I can't just ask for current slot and current performance number
Thanks for trying to help.