CK: NRPN Advanced MIDI documentation request

    Quote from timo

    All parameters are 14 bit values, so you need to address the whole 14 bit value*[1]. Send 98,99,06 and 38. Send 38 as last controller. The reception of controller 38 will set the value. The LSB is required to be set. Data Increment/Decrement is not supported.


    Timo

    Timo, so it is not possible to have expression pedal -parameters to adjusted with that 14 bit system (delay mix)?
    -Olli

    Quote

    All parameters are 14 bit values, so you need to address the whole 14 bit value*[1]. Send 98,99,06 and 38. Send 38 as last controller. The reception of controller 38 will set the value. The LSB is required to be set. Data Increment/Decrement is not supported.

    Thanks, timo. But this is only half the story. What you describe is the MIDI sequence for high-resolution parameters. KPA also supports low-res programming. See pages 1 and 2 of the docs:


    I actually tried both, and every permutation of swapping MSB/LSB of the location and value, without any luck.


    Something just occurred to me, though... I recently restored Maurizio's backup file. If he's got the KPA MIDI Channel set to anything other than the default Omni (or by sheer luck ch. 4) my script won't work (per the hex B3 in my last post). I'll have to double check that tonight.


    Random aside: everyone else in the world uses "#" to prefix a hex value; is "$" a German thing? Or a Kemper thing?

    Quote from mbenigni

    What you describe is the MIDI sequence for high-resolution parameters. KPA also supports low-res programming.


    No, it does not. All parameters are high resolution per definition. Although the MIDI 1.0 spec from 1995 is a bit vague about it, like proposing that _after_ selection of a controller (with 98/99): "However,.., it is recommended that the LSB and MSB be sent each time a new parameter number is selected"[1]. Later addendums to the standard (like the "MIDI messages" document[2]) propose that the receiving unit needs to define what a controller is, 7 or 14 bit. KPA is all 14 bit, so you need to send it.


    Since the MIDI specs talk[2] about "If the selected Registered Parameter requires the LSB to be set, send another Control Change message to the Data Entry LSB controller (Control Number 38). ". The KPA requires LSB to be set.


    Timo


    [1] MIDI 1.0 Detailed Specification 4.2 - 1995, Page 17 (unfortunately, you can only buy a paper copy if this)
    [2] http://www.midi.org/techspecs/midimessages.php

    Quote from mbenigni

    So are you saying the KPA MIDI Parameter Guide is inaccurate? I'm quoting from it directly in my last post.
    (Bear in mind that the document also explicit states that the Kemper implementation differs from the MIDI spec in this regard.)


    It looks that way. I know better, since I wrote the decoder code myself. The KPA is MIDI compliant.


    Timo

    Quote from mbenigni

    Random aside: everyone else in the world uses "#" to prefix a hex value; is "$" a German thing? Or a Kemper thing?


    Actually, $ has always been the prefix for hexadecimal numbers in compilers and assemblers for decades. "#" comes from the www, where colors are expressed like "#aa99cc". Today, programmers are often using "0x" as prefix, as it is the prefix in C/C++.


    Timo

    Quote from timo

    Actually, $ has always been the prefix for hexadecimal numbers in compilers and assemblers for decades. "#" comes from the www, where colors are expressed like "#aa99cc". Today, programmers are often using "0x" as prefix, as it is the prefix in C/C++.


    Interesting. I'm familiar with the 0x prefix, of course, but I've never seen the $ before (well, not in recent memory at least.) Anyway...


    As for the rest, it turns out we're both about half-right, and the Kemper document is at least half-wrong. Low-resolution programming is supported as documented. You can either omit the LSB altogether, or simply send an LSB of 0. (I assume that the KPA's internal smoothing is applied in the former case, but defeated in the latter case.)


    However, the Kemper document is wrong in stating:


    Quote

    This is what you send for low resolution values (7 bit):
    $B0,$62,Address Page
    $B0,$63,Address Number
    $B0,$06,Parameter Value


    That last byte should in fact be $26; Kemper has confused the LSB and MSB here.


    That same passage is also inaccurate (or all of the subsequent module descriptions are inaccurate) in confusing Address Page and Address Number. I'd been sending $62 $0A, $63 $04 to program Amp Gain (per pages 2 and 3 of the documenation). In fact, it needs to be $62 $04, $64 $0A - address then page vs. page then address as described. If anyone from Kemper is reading, this documentation needs to be proofed and corrected. (This probably only impacts users, who are programming NRPN by sending discrete CC messages. I take it software that supports NRPN "out of the box", like TB MIDI Stuff, works OK, since folks have already had success.)


    So, finally, here is the MIDI sequence to drive the Gain parameter, and the corresponding Event Processor Script to send this sequence on receipt of MIDI CC#3:


    Quote

    B3 62 04
    B3 63 0A
    B3 26 yy



    Now I've got an Event Processor Script that lets me control KPA Amp Gain with the GK Volume on my Roland-Ready Strat, and Stomps B C D MOD and DLY with a MIDI Moose. (There are only 5 switches, and I often use Stomps A and X as pre- and post- loops anyway.) Next step is an iPad editor for deep-editing effects. I'll probably use TouchOSC since it's basically the devil I know.

    No, you will need to send "Bn 63 0A Bn 62 04 Bn 06 mm Bn 26 ll"
    where n is the MIDI channel (usually 0), mm is the upper 7 bit value part and ll is the lower 7bit value part.
    Timo

    Quote from timo

    No, you will need to send "Bn 63 0A Bn 62 04 Bn 06 mm Bn 26 ll"
    where n is the MIDI channel (usually 0), mm is the upper 7 bit value part and ll is the lower 7bit value part.
    Timo


    Again, they are both supported, per the documentation. What you describe is the high-resolution variation, what I have posted is the low-resolution variation. I already have this working.