Posts by slateboy

    A bit annoying that you now have to choose between head/rack/stage/player when making a new post when that post may apply to all. (can we have an "all" option or at least a multi-select option?) if not, it may somehow be the answer to this question...

    Now we have a "one firmware update for all units" can anyone clarify if this is a "bundle" update, ie firmware for each separate unit in one file and the relevant device "reads" the part of the firmware that is applicable to the unit concerned.
    OR
    it is actually the same firmware for all units but each unit only uses the code within that FW specific to itself and ignores code for the other units?

    It is clear there are physical and operational differences between units, hardware and operation so i wonder how the architecture applies.

    Recent updates/fixes only address issues to particular unit (head/stage/player) and therefore appear not applicable to the others, hence, there may be no benefits to updating the player FW if the latest FW addresses an fix/issue for the stage.

    Does that make sense? :/

    I have implemented first benefits of a bidirectional communication with KPP.

    But you can try it: https://github.com/gstrotmann/MidiCaptain4Kemper

    Very interested to learn more about your project and custom firmware.

    Which versions of the pain-audio pedal does this support?

    Some video demoes would be highly appreciated so users can decide if they want to pursue this. Please share some when you can.

    thanks

    Clarification needed please. Is the beat-scanner function available in LEVEL 1 or is it a paid upgrade?

    it appears to have been there in level 1 v11.1.2 firmware but today i installed v11.1.52 and can no longer find it.

    Here is evidence it was working, in v11.1.2 level 1

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    No reason to spread uncertainty and doubt.

    Perhaps a different thread title would be more appropriate? i apologise.

    To be clear, here the Player crashed always because of me and my code 😂

    Partially reassuring that i am not alone and take some responsibility in my crashes. I dont think that AleFretMaster intends to spread doubt either.

    I only wish to share my own personal experiences with no intention to scare users nor criticise the firmware. There's a lot of new stuff happening right now and we all work together to make it the best possible. However i do believe it is worth mentioning in case any other users have unexplained issue that may be similar. (and the video demo showed this) After all, that is one of the purposes of these forums.

    On a similar note, i had an issue in the past (completely separate to this one) where a problem persisted for a few years (not serious and a workaround was found) yet support could not reproduce the problem. Eventually, after conversations with support, a solution was arrived at by support that resolved the issue which appeared unique to me.

    i have nothing but praise for support who helped and corrected me with the matter and, as a working professional musician, rely on my kempers where reliability and dependability is why i have been using kemper for over 10 years.

    take a look here

    AppleTreeChen
    March 22, 2024 at 1:51 AM

    Is this reproducable? Is there an error message?

    This should not produce any problem.

    I did forward this issue to support and they corrected me on my "bad" midi data. Admittedly, my fault for gettign the midi wrong, however, even though support replied, i am not sure if a fix was put in place.

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    This could act as a warning if you are pumping lots of midi data out, perhaps as part of your show, and your Kemper may be open to receive some "illegal" midi data.
    I am also curious to know what protection there is in regard to any kemper (let's use the player for this example) when receiving too much or "bad" midi data.
    What i mean by "bad" midi data is midi that is corrupt, not by hardware fault but perhaps the wrong messages are being sent. I recall fixes being put in place (ages ago) that prevented midi buffer overload, which used to cause similar issues.

    i recently tried to change an FX slot using midi NRPN data. Much control of all kempers can be done this way. However, i got one value wrong and every time i sent this "bad" mid data it crashed the Kemper and made a loud whining noise. Believe me, you wouldn't want this to happen during a live show.

    Here is an example that crashes my player:

    BAD midi that crashed the unit:
    CC#99 50 (module A)
    CC#98 0
    CC#50 0 WRONG CC NUMBER (should be CC6 not cc50)
    CC#38 100

    Correct Midi is
    CC#99 50 (module A)
    CC#98 0           
    CC#06 0 (effect type acoustic simulator)
    CC#38 100

    If you are relying on midi control from external sources (some people have sequencers controlling their KPAs) and this kind of midi data gets sent you need to be sure it wont mess things up.

    Should the Kemper detect and reject this bad midi data?

    not that I know of. I actually wasn't even aware up to this point that the LEDs around the gain knob are multicolor at all. They could probably be much more usefull than merely signalling what upgrade LVL the player is, using them much more dynamically, e.g. to show morph status (blue to red) much more visible than the green-green leds next to the footswitch.

    nice idea- forward that to the features request dept