Posts by timo

    Well, referring to the "Profiler MIDI Parameter Guide" document, KPA accepts NRPN messages with the structure:
    - cc 99 - address page
    - cc 98 - address number
    - cc 38 - parameter value LSB
    - cc 6 - parameter value MSB

    There is a mistake in the document, it will be corrected. You need to send (as defined in the MIDI specification for 14 bit NRPN) first cc6, then cc38. The KPA takes the value when cc38 is received.
    With the 1.5.1 firmware, there is also a fallback for 7bit values, in this case, you can send cc119 to set the value. This way, a correct mapping from 7 to 14 bit is guaranteed.
    Timo

    Another thing that's happening a lot is i switch the rig, it shows the new rig name on the screen, but the sound stays the same, sometimes it changes to the new rig displayed (as it should), other times it doesn't, no matter if i switch via the footswitch or the browser Knob, this is with the "Autoload" of course engaged. I give up !!

    I assume that the actual rigs are deleted, yet, the data structures think they are still there.


    You can fix this by creating a backup and restore the KPA from it right after it. During reboot, the sound content gets rescanned.


    Timo

    just read the "announcement"about having less than 1000 rigs and other potential problems,not impressed.


    The known issues list shows about a problem when you are downgrading to older versions. Basically, there is a bug in older versions that prevent a proper reading of a few global settings introduced in 1.5.0 (which happens when you are going back to an old version). Since the bug is in the older version, it can't be fixed, therefore it is listed.


    Timo

    it doesn't have enough space left in the memory to create the file

    No, memory cost is one rig at a a time. Nevertheless, I recommend downsizing pretty soon. Don't keep more than 1000 Rigs in the machine. Apart of that: "Export all Rigs" does not export local presets and global settings, so a backup is complete, "export all rigs" is not.
    It takes that long since the filesystem on USB sticks is not really good in handling lots of files, a backup wins here, too, since it is just one file.
    Timo


    Yes I also get this "Tuning Storage" message every single time with 1.5

    This is indicating the difference in boot time between fast and not so fast. Nothing changed, except the process is being displayed now. Check if it does get faster when you switch the KPA properly off with the chickenhead switch.
    Timo

    Fortunatly I read the tips from Armin (shouldn't there be a troubleshooting chapter in a manual ?) and fortunatly I had an usb stick (with latest firmware update and backups) with me.
    Started with [<> + Main knob to tuner] to reinstall from stick : message ".. cannot find software ..." (it was in the "OS Updates" folder like set up by KPA). Copied the .bin to main directory (even a notebook was there ) and tried again. Began to install from stick ... after finish (thaught so) message : "unable because of multiple versions..." (there still was the same version in the "OS Update" folder) ... but then he turned on and all settings where still there

    Reinstalling the firmware does per se not solve any of these issues. Armin's guide is misleading regarding the largest part of problems. The initialization of the flash memory was only necessary after a bug in 1.0.5 where a memory corruption bug could also mess up the flash memory organisation.
    For your actual problem, please contact support.
    Timo

    is there any way to prevent it from happening?


    In this case the clock is not working right from the start (though it is being checked in the production, so maybe something happened during transport).
    Previous firmware versions just did not check for that fault.
    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

    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

    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

    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