3.2.1 FIXES THE DIGITAL CRACKLING / HASH :) => 3.2.0 ....BUG ..... still has the hi-freq-digital-crackling / hi-freq-digital-hash when Changing sounds in Browse mode ...

    Quote from meambobbo

    I said above that performance mode is unacceptable and this needs to be high priority


    And i agree. I love my Kemper but beta releases should not be elevated to final releases with such an issue being known.

    And in the end, the love you take is equal to the love you make.

    Kemper has always said they could not reproduce and assumed it was due to switching between specific effects heavy rigs. I havent tried to reproduce for a while now, but havent heard it since going to 3.2, which isnt saying much but it was very rare for me

    Having read rather many experiencing this with 3.1.4 and 3.2.0 (and some saying something similar was there pre-3.0 FW) and considering people have sent their backups to support, I'd be surprised if KPA team wouldn't be able to reproduce this already. I'm personally gigging with Browser mode and this is annoying bug to say the least!

    OP here again.


    I have tested extensively going from 3.0.2 to / from 3.1.4 and 3.2.0 repeatedly and many times - this issue does not exist or occur with 3.0.2 but definitely does occur with 3.1.4 and 3.2.0.


    I also know that so far Kemper cannot reproduce it - which is really surprising given how many users are reporting and getting it.


    I'm sure Kemper will [eventually] fix it ...... but it is really annoying and incredibly disconcerting when it happens ..... and during long-gigs [ ie: 3 x 1 hour sets ] it occurs several times :(


    Ben

    Hello Fellow Kemperians,
    Unfortunately in my opinion sending your dumps are not going to solve this issue... Why you say ?
    Because these reports began springing up right around V3.12 and obviously are still present. Why is this relevant ?
    It is my opinion from the standpoint of substantial experience in this subject that the problem exists in the actual firmware Assembly program output.
    In other words " Program mapping Errors ! " It is not a preset parameter variable problem ! Any good programmer would have checks in place to limit values and check for valid parameters....
    Now we get into the murky grey depths of programming madness.... What I feel we have here is several possibilities.


    1. Memory Overlap caused by a rouge uninitialized pointer or (M) boundary register.
    2. Compiler error
    3. Midi Stack Overflow
    4. Memory leak caused by a missing (return) or some syntax error that was not caught which is blowing up the stack pointer !


    Why do I think this? It is logical to assume if it was a typical program bug ... More people if not all that have updated to any of these versions would be complaining.
    The fact that these things are being reported in a random nature leads me to my suspicions.....
    I will admit from a programmers view we would like the job to be made easier if the users can provide a do A+B+C to reveal the bug! For UI stuff and general repeatable bugs this is great.
    But for random bugs like this .... Its a completely different ballgame ... If the programmer is relatively (Green) Less than 10 years experience ... There is going to be problems like this in every release moving forward !
    Mr Kemper needs to get into the bowels of this personally .. comb the program .... Compare the V3.02 (Last true stable version) to 3.12 , 3.13 or even 3.14 confirm the program output , New code , anything that has changed .... I am trying to help you guys here... This needs to be addressed and solved definitively with an absolute resolution. Otherwise the JENGA affect is going to cause some severe reputation damage moving forward. Hope this wakes someone up at wheel. Thanks

    Just to add my 2p, I noticed this with 3.2 release through the power amp into a guitar cab, using merged profiles with the same cab preset (although obviously this wouldn't be used!) no effects (maybe reverb locked on but almost certain it was locked off) on either profile, global noise gate on input section at 0, using the remote. It's occasional, fine in a beta but really shouldn't be in a release version after being reported so much in the betas.

    SgtPepper is on the money.


    Whilst I know nothingabout coding / programming etc..... I / we do know that:-


    a - this problem absolutely does not exist in 3.0.2
    b - this problem absolutely does exist in every FW after 3.0.2
    c - rolling back to 3.0.2 - problem disappears
    d - upgrading to any FW after 3.0.2 - problem re-appears
    e - repeating c + d multiple times confirms the same issue = 3.0.2 good - everything after 3.0.2 bad
    f - doing a re-initialization and/or full system reset does not fix the problem
    g - setting the Rig Cross-Fade to max. value does not fix the problem


    The only actual factual conclusion is that something done after 3.0.2 has caused this problem.


    So, given the FW is only around 8mb in size, I'm thinking a line-by-line code comparison between 3.0.2 and [say] 3.2.0 surely cant be that onerous a task.


    Ben

    Quote from DamianGreda

    8Mb of code will take ages to compare. This is bad idea.
    Can someone post Audio sample?


    But surely this can be done in an automated way ?


    Plus, in the first instance you would only need to isolate


    (i) only 3.0.2 lines of code that were edited and
    (ii) new lines of code added after 3.0.2


    This would narrow the "search field" massively would it not ?


    Either way it will take time ....... but this isn't brain surgery !! ....... and ...... the fact that this issue is present in every FW since 3.0.2 -and- 3.2 was elevated to "release" without a fix suggests that Kempers current de-bugging-process isn't optimal and/or they have hit a de-bugging "brick wall" .... so a more back-to-basics approach may well be the best way forward.


    This isn't a 6GB Windows 10 installation with 50+ million lines of code :)


    None of this is a criticism by the way .... just putting ideas out there to try and spark some ideas about an approach to find and fix this issue.


    Ben

    Edited 2 times, last by benifin ().

    I understand your thinking Ben but actually like DamianGreda stated, "ages". 1Mb of text single spaced on a page would equal about 250 pages (x8) for KPA code. And code usually isn't full sentences on each line so factor that into the equation.


    Teamwork will get this solved I'm sure. If not, like Sgt. Pepper stated, probably the new guy that did it, haha ;)

    Don't get me wrong .... I have %100 no doubt Kemper will find and fix this issue ..... period.


    But ........ elevating 3.2 to release with this issue still clearly present " threw " me and others a lot ..... not the sort of thing Kemper is known for ....... I mean this is a pretty big [ annoying ] problem .... changing rigs via Midi ..... something that has been silky smooth since 1980 .... and silky smooth in 3.0.2 ...... is now [partially] broken in every FW since 3.0.2 ...... and yet 3.2 comes out of beta to "release" / "final" with the issue still there ??


    But again, I have %100 no doubt Kemper will find and fix this issue ..... eventually .....


    Ben

    I never had it before, but I just upgraded from 3.0.2 to 3.20 and now I heard it for the first time. :|
    I upgraded to have the Pure Cabinet function, which was not in the 3.0.2 version.


    I heard it for the first time when I checked almost all my profiles (in performance mode) to check which PureCab setting i needed, and it appeared after checking about 9 other perfomances. I switch on PureCab on a Rock n Roll performance (Silverclone Nashville) and it appeared! Not before on JCM800, mesa, JMP, TwoRock, but only at this amp.


    So, could it be in the PureCab function? This Pure Cabinet function was added AFTER 3.0.2

    The KPA made me GAS again!

    I have the digital crackling issue since 3.1.4 using the Remote in both Browser and Performance mode. I am now on 3.2 release and did some testing.
    The problem in Performance mode always occurs when switching between the same patches. It is completely reproducable. When I deactivate the delay OR reverb in the slot that I am switching to (and save the performance). I am able to switch crackle free. When I leave both engaged in the target slot (the slot I am switching to), I will get crackling again.


    This does not occur in all slots with both delay and reverb engaged, only a few. For now I leave reverb disengaged on the problem slots.


    Can someone confirm this?


    Thanks, Roel

    Any gear that produce unpredictable audio quality is unusable for live purposes in my book. None of the versions post 3.0.2 should have been elevated to release-status. It is time for Kemper to pull all post-3.0.2 releases, then issue a 3.2.1 or 3.3-beta from the current codebase for the adventurous crowd to test and work from there.

    Got it again last night, sound cutting in/out & crackling for about 3-5 seconds after previewing several different rigs in browse mode. It happens immediately after loading a new rig, haven't noticed it happening after a rig has been loaded for a short time.

    Quote from heldal

    ........ None of the versions post 3.0.2 should have been elevated to release-status. It is time for Kemper to pull all post-3.0.2 releases, then issue a 3.2.1 or 3.3-beta from the current codebase for the adventurous crowd to test and work from there.


    I think this needs to be done.


    There are now numerous unique users posting this issue occurring multiple / random times.


    3.0.2 should be "re-elevated" to current release and all other current post-3.0.2 should revert to alpha/beta status.


    3.0.2 went "release" on March 30 ...... 7 months later and several " FW's " later this problem is still there.


    I love my Kemper and I'm not "going anywhere else" gear-wise, but this is just not good enough.


    Ben