MIDI Chasing / Selecting Banks and Programs

    Hi, I'm using the lastest version of Cubase 11 (Win10, 64bit) and the latest Kemper OS (8.6.6.xxxxx) on my Kemper Head.


    Cubase sends MIDI messages to my Kemper to change the sounds. For every song, I use a separate bank. So I can use 5 sounds for every song - what's enough for me.


    Until now I changed the banks and programs on the Kemper with MIDI-programChanges which worked pretty well.

    With the songs of our new album we have a total of 29 songs. This means I can not address all the sounds with programChanges due to the limitations of MIDI.


    So I switched to ControlChanges (#47 for the bank and #50 - #54 for the program). But now I run into problems: Sometimes my Kemper hangs, sometimes the change does not happen and when I stop in Cubase, the Kemper changes to a false program.


    Does anybody uses a similar setup and encounters similar problems? Any ideas are welcome to solve this!


    Little remark:

    Maybe it would be better if the Kemper changes the programs in a bank with just one ControlChange that varies the values (for example uses always ControlChange #50 and value 1 is program 1, value 2 is program 2 and so on). This would minimize the problems with MIDI chasing in DAWs - meaning to follow the song and automatically set the right sounds on any position in a song.

    The better approach would be to stick to the absolute addressing method loading Slots.


    You need to enhance your MIDI program changes by MIDI bank select LSB. I guess, Cubase can do it.


    Send MIDI bank select 1 (which is CC#32 value 1 or 0) to navigate within Performances 1 up to Performance 26 Slot 3.

    Send MIDI bank select 2 (which is CC#32 value 2 or 1) to load Slots beyond that range up to Performance 52 Slot 1.


    You find the bank select and program change address for each Slot in the dark box on the left side of the display, if no Remote is connected.

    Hi Burkhard,

    thanks for your quick reply.


    In the mean time I figured out what the problem was - and because it might be interesting for others, too, I try to explain which solution works best for me.


    I'm still using relative addressing because it has the advantage that I only have to change the first ControlChange (#47) in the beginning of the song that switches the Kemper to the right performance. So if for example I would reorder the performances in my Kemper I only have to change this first ControlChange (#47) to the new value per song.


    My problem was, that Cubase - like probably most other modern DAWs - is using the so called MIDI chasing. This means that if you jump somewhere in the song, Cubase takes care that all connected MIDI gear gets the commands to load the right sounds. This is pretty good. For example if we decide in the rehearsal room to start at the chorus, Cubase switches my Kemper to the chorus sound. And this worked with no problem at all if you only use ProgramChanges.


    But now with the new addressing system that I use, every slot in a performance has a separate ControlChange (#50 - #54). For example if I would like to change to slot 3 I only have to send CC#52 with a value greater than 0. If I then would switch to slot 5 I have to send CC#54 - and so on.

    But if I now stop and go for example to the first chorus, Cubase checks ALL ControlChanges for their last value and sends these values to the Kemper. In the worst case this means the Kemper gets CC#50 - CC#54 with values greater 1. So the Kemper does not know to which slot he has to switch. And this is probably the reason why my Kemper sometimes hangs and I had to reboot it.


    BUT HERE IS THE TRICK, which fixes the problem: Every time when I send a ControlChange that lets the Kemper switch to a slot I also send the ControlChanges for the other slots with value 0 - just a short time before.

    Example when I want to switch to slot 2: I have to send: CC#50(value 0), CC#52(value 0), CC#53(value 0),CC#54(value 0) and a little later CC#51(value 1 or greater).


    Though this seems a little complicated you only have to create it once for each of the 5 slots and then you can copy and paste it. To even better visualize it I gave each slot a unique color (s. example attachment).


    Best regards

    Bernd

    Thanks BerndBloedorn that was REALLY helpful ?


    I haven't been using midi to change rigs as the Remote and my big clumsy feet have worked nicely until now. However, I may be about to start working with a band that runs everything from a laptop including the click track. Therefore, I wanted to familiarise myself with what I would need to add to the session to make my rigs change automatically. I read up on the midi implementation manual last night and decided that I much preferred the simplicity of sending a CC for performance and second CC for slot rather than trying to constantly calculate the correct PC (the CC method also seems more logical and easy to change if songs or rigs are reorganised)


    I created some midi regions in Logic and tested a few rig changes. It all worked well EXCEPT for the exact problem you described. Every time I stopped playback the KPA selected a temporary holding rig but when play restarted midi Chase didn't catch the correct rig. The correct rig only loaded when a new midi command was sent. This was driving me crazy and I could understand the cause. I checked and rechecked all the midi Chase settings in Logic but nothing worked. Your explanation makes perfect sense so I look forward to getting this working tonight ???

    Quote from BerndBloedorn

    BUT HERE IS THE TRICK, which fixes the problem: Every time when I send a ControlChange that lets the Kemper switch to a slot I also send the ControlChanges for the other slots with value 0 - just a short time before.

    I do the exact same thing. I don't think it needs to happen before the actual switch -- I usually just send all five CC's (50-54) simultaneously, all zero except the one I want to switch to. But yes, definitely the right solution!


    (For anyone wondering: alternatively, you could always stick with the basic "footpedal button press" idea and just send the same CC twice in short succession, once with a non-zero value (to activate the slot) and then with value zero (to "take your foot off the pedal"). A short "click", as it were. But then you wouldn't get the benefit of MIDI chasing if you start the song in the middle of a section, since all of the CC's would then be zero most of the time. For that reason, it's best to keep the CC for the desired slot at non-zero for the whole duration of the section where that slot needs to be active (as if constantly keeping your foot on a button) -- as long as you remember to "clean up after yourself", i.e., make sure all of the CC's for the slots you don't want active are reset to zero.)

    This is from the Main Manual in context of CC# 50-54 functionality:


    To support all functions, values 1-127 should be sent when the button is hit, and value 0 should follow when the button is released.


    If you would always send each of these CC# 50-54 e. g. CC# 51 with a value of 1 immediately followed by value 0, wouldn't that avoid the need to send these stacks of redundant value 0 messages?

    Hey Burkhard , you're describing what I called the "footpedal button press" approach in my post above, essentially imitating a short on/off click of a momentary footswitch. You're right, it works fine and is a good option for many people!


    The reason for not resetting a CC to 0 until you switch to another slot is that it allows you to start playback anywhere in the song. MIDI chasing will trace that CC back, find out that it was set to 1-127 at the beginning of the section, and re-send that value to the Kemper, so that the Kemper switches to the appropriate Performance slot, even if you haven't passed the start of the section where the switch is programmed.


    So as long as you make sure no two of CCs 50-54 are set to 1-127 simultaneously, MIDI chasing can be quite useful!


    Of course, even with that method, it isn't necessary to send all five of those CCs for every slot switch: it's enough to only set the previous one to 0 and the new one to 1-127. Sending all five every time (four of them 0, one 1-127) is just a redundancy thing I do: when you're writing a song and moving things around, it's harder to keep track of what CC has been "activated" in the previous section and should be turned off next. Turning all of them off every time (except for the one you're turning on) helps to make sure there are no stray CCs accidentally left on.


    But again, you're right, in many cases a quick "button hit and release" is a better, and certainly more straightforward option!

    Hmmm, neither of those seem to be working properly for me. Every time I stop playback the KPA screen goes grey and the Load and Exit soft keys flash awaiting a command. This state is maintained until playback passes the next CC command.


    Also tried the absolute method of CC32 then PC# this isn't working properly either.


    This reminds me why my midi foot controller is in a cupboard and I just use the Remote.:cursing: Despite its limitations the Remote is totally plug 'n' play and just works beautifully. :)

    Robrecht Ok, thanks, understood! I guess, you are disabling Rig Button Morph as otherwise there could be confusion. Morphing can be controlled via CC#80 anyhow.


    Wheresthedug I don't understand the issue with bank select LSB + program change. That function is very straight forward. The MIDI channel has obviously to match. And you cannot load disabled Slots. What isn't working properly?

    The chase didn’t catch the previous rig until playback passed the new PC.


    However, it is now like it has frozen. It changed the first time but then went to the loading waiting status and won’t change again. I have rebooted the KPA, closed, opened RM, connected and disconnected Remote, restarted Logic, rebooted computer but nothing will cause a rig change now.

    I guess "loading waiting status" means "pending". This should never happen, if you just use the absolute method (bank select plus program change). You are adressing a particular Slot, there is no reason to wait for anything. The setting of Performance Load is irrelevant.


    I cannot reproduce such a scenario. Make sure, you are not mixing with the relative method based on control changes # 47-54.

    Hi Burkhard, yes I did mean pending. It was happening all last night with various different methods of sending midi data. I definitely wasn't mixing it with the relative method. It happened both with Absolute and Relative (not a combination of the two together). Hoqever, It is all working perfectly tonight. Computers don't generally work one day and not the next so when this happens the cause is most likely user error. I have no idea what I did wrong but will continue to keep an eye on it and try to figure it out.


    Perhaps you could also explain to a technophobe like me how to use NRPN. I have read the midi implementation manual several times and to be honest it might as well be Mandarin to me =O If I am using a DAW like Logic, how do I enter the required NRPN commands to send to the Kemper? Can this be done within the DAW? Does it need a stand alone editor? Can you just type the various part of the command in a line of text or does it need actual programming language too?

    NRPN is just 4 CC send in quick succession. They have to have specific numbers:


    1. First is CC#99 - aka NRPN-MSB
      Value corresponds to address page from KPA's MIDI manual
    2. Second is CC#98 - aka NRPN-LSB
      Value corresponds to parameter number from KPA's MIDI manual
    3. Third is CC#6 - aka Data MSB
    4. Forth is CC#38 aka Data LSB

    Data MSB and LSB together form a value for parameter addressed by page and parameter number.


    For On/Off parameters CC#6 should be 0 and CC#38 should be respectively 0 and 1.

    For parameters which have continuous values (like volume, morph) you can specify any value for CC#6 and CC#38.

    You can think of value provided with CC#38 as ones place of a two digit number and value provided with CC#6 as tens place of two digit number.


    For example in Logic this should turn amp on:


    Remember to space out MIDI messages by more than one tick - don't sent them all at once (look at position in the screenshot) - too many MIDI messages sent too fast == KPA crash.

    MIDI is based on 7-bit values, which supports a range of 0-127. NPRN combines two 7-bit values, which allows a range of 0-16383 (128*128).

    This way you can adress much more than 128 parameters and you can realize a better resolution of a continuous parameter like Delay Mix.


    You see in the example above that two 7-bit comands are combined: MSB and LSB (Most/Least Significant Byte).


    Example: You want to load a Crystal Delay into Modul DLY.


    You use CC# 99 and 98 to send the parameter. Effect Type of Module DLY, which is:

    CC # 99 value 60 adresses effect module DLY

    CC # 98 value 0 adresses effect parameter Type


    Then you send the value for Crystal Delay, which is 150. This is split into 1*128 + 22, which makes:

    CC # 6 value 1

    CC # 38 value 22


    We have just released a new and enhanced revision of the MIDI Doumentation, which is in line with OS 8.6.


    Instead of sending 4 Control Changes you can also send one Sysex message.

    The Sysex message corresponding to my example above looks like this:


    F0 00 20 33 00 00 01 00 3C 00 01 16 F7


    These values are hex:


    60 d = 3C h

    0 d = 00 h

    1 d = 01 h

    22 d = 16 h


    The rest of the message is administrative overhead explained in the NPRN document.

    I don't think you can enter sysex directly in Logic. You'd have to "record" it first on a midi track and then copy and paste. But I personally would stick to regular CC, something you can edit in Logic.


    Pro tip: you can copy and paste all four Midi CC events in Events table and while new events are still selected you can edit position of all four messages at once. This makes entering NRPNs less annoying.


    Pro tip #2: if you want to do a ramp (gradually change value of given parameter) it should be enought to just repeat CC#38 with new value. You can record such events as automation in Logic.