New update 1.0.6

    Quote from eatapeach

    Difference between 2 and 3 is clear and it does sound like the cab has changed - I wonder if the change to the next profile preloads the cab of that profile (in code) and doesn't release it if you switch back to the first profile. What happens if you put the same profile next to itself and do the switch then? What happens if you put two profiles with the same cab next to each other and do the switching around then?


    I'd test it myself but I'm not going to 1.04 until we have the issue ironed out and I don't have the problem.



    Unfortunately it's not a cab change. I have the same problem when I switch between two rigs using the same cab. On start up Rig 1 (normal sound) then switch to Rig 2 (same cab as Rig 1) back to Rig 1 - sound changed - more scooped and more presence/fizziness and also slight increase of volume (about 1 db). For now my workaround is to engange a master eq where I cut a little bit of presence and increase midrange by about 0.5 - 1. Works ok until the fix.


    Besides this ugly bug 1.06 seems to be really cool and stable I think. So, I hope they manage to fix that soon and then we are all rocking again.


    Hi, just an advice to be more precise in the comparison. I clearly ear differences between the two tracks, but it is very important they sound EXACT the same from the beginning, so, even if you use same guitar, same pickup etc... but you are playing a different TAKE, the sound will be different!
    Can you (or others too) next times use a looper with the same take? It will be in this case definitively a REAL comparison with no more doubts!
    Try it... believe me... 8)

    Quote from MaxTwang

    How's the latency compared to 1.0.5?


    UPDATED
    I miss a substraction in previous ONE and I did some more accurate measurements, here you have the results...


    The conclusion is that latency is a little worst then in the 1.0.5, but still good compared to 1.0.4.


    Here you have the data:
    1.0.4 latency was about 207 samples (4,7 ms);
    1.0.5 latency was about 107 samples (2,43 ms) (and THE BEST TILL NOW reached and that really meets the specifications);
    1.0.6 latency was about 134 samples (3,04 ms)...


    I try before and after System restart, and the latency is exactly the same, so no need for that.
    Also, indipendently from the measurements method (anyone has its), I use always the same for every KPA version, so at least the comparison from them is totally effective.


    Did anyone measure it? I believe that on latency the Kemper Profiling Amp still must find his stability :|
    Also I noticed little difference latency depending on the chain effects used (with others MultiEffect consolle this not happened).
    For example I measure that in 1.0.6 if all the chain is off (also Stack module off) latency is 2,6 ms.


    Maurizio70

    Thanks for the measurements Maurizio!
    I hope this latency increase is only a temporary fix for the pops, and soon the developers will find a better solution. Anyway.. more communication would be very much appreciated from the Kemper team.

    Quote from Maurizio70

    Hi, just an advice to be more precise in the comparison. I clearly ear differences between the two tracks, but it is very important they sound EXACT the same from the beginning, so, even if you use same guitar, same pickup etc... but you are playing a different TAKE, the sound will be different!
    Can you (or others too) next times use a looper with the same take? It will be in this case definitively a REAL comparison with no more doubts!
    Try it... believe me... 8)

    Thanks for the tip, Maurizio. That's very true. I tried playing something similar and I think the sample I did was good enough to demonstrate the difference, but yes, only a looped signal will be a truly 100% accurate comparison. Only prob is, I don't have a looper around.

    I have measured the latency on firmware 1.0.6:
    Based on my measurements: If only the stack is active it is approximately 3.3 ms.
    Yes, it varies a bit with the effects.
    However I have noticed a strange thing: when deactivating an effect the latency jumps to appox. 5.2 ms for a few seconds. After it settles back to ~3.3 ms.

    Exactly the same results for me after downgrading to 1.0.5.
    Now let's see 1.0.4... :)

    Yes, as expected on firmware 1.0.4 the latency is increased to ~ 5.2 ms. Note that this value is the same as the temporary latency on 1.0.5/1.0.6 when deactivating the delay for example. This glitch is only a few sec on the newer firmwares though... after it goes down to 3.3 ms.

    Sure, I'll drop a mail to support.
    Well based on my measurements I'm pretty confident that both 1.0.5 and 1.0.6 have the same latency: around 3.3 ms if my measuring method was correct. (I have used CEntrance LTU program + my RME 9632 card).

    Quote from DanielRigler

    Sure, I'll drop a mail to support.
    Well based on my measurements I'm pretty confident that both 1.0.5 and 1.0.6 have the same latency: around 3.3 ms if my measuring method was correct. (I have used CEntrance LTU program + my RME 9632 card).


    Daniel, I update my previous post and do more accurate measurements:
    1.0.4 latency was about 207 samples (4,7 ms);
    1.0.5 latency was about 107 samples (2,43 ms) (and THE BEST TILL NOW reached and that really meets the specifications);
    1.0.6 latency was about 134 samples (3,04 ms)...


    So, based on my tests, from 1.0.5 to 1.0.6 latency is very similar but not exactly the same... And thanks for your additional testing!

    Maybe my measuring setup is not as precise as yours... How do you measure it? Also what is the state of the STOMP / STACK / EFFECTS buttons. Do you measure on the same patch? Did you do a system initialization? Do you use the analog INs / OUTs?

    Also note that I have found you need to leave a few seconds for the unit after you make some changes to the patch in order for the latency to settle at the minimal values. These are probable due to some "housekeeping" activities inside the KPA. I'm not sure. Changing to a different patch can also introduce small latency changes even if only the stack is active. Oh and by the way I have used the front panel input and the main analog out for my tests.

    Edited once, last by DanielRigler ().

    Quote

    Omg!! I've just read this thread and all the comments. I haven't updated my unit to 1.06 yet. Tomorrow I' ll check this bug,my current Fw is 1.05 but I didnt notice this problem previously. I'll let you know asap


    Just for the record - it isn't present in .6895

    Quote from DanielRigler

    Maybe my measuring setup is not as precise as yours... How do you measure it? Also what is the state of the STOMP / STACK / EFFECTS buttons. Do you measure on the same patch? Did you do a system initialization? Do you use the analog INs / OUTs?


    I measure before the latency of a chain (without the KPA) with a Send/Return loop active (only a single cable), after I simply substitute the cable in the Send/Return loop with the KPA (Analog Input/Output) and re-measure the latency. So, the latency introduced by the KPA is simply the difference between the previous two.
    Measuring it using the same chain and then make the "difference" with/without the KPA is very precise because it remains independent from all the other stuff used (cables, audio soundcard and so on). All measurements were done with only STACK module ON and using always the same patch. It's not easy to explain, so I hope it was understandable ;(

    Thanks for the info. I have measured it in a similar way.
    Anyway... lets hope for some official clarification soon. All these different results / bugs...etc. are very mysterious. :)

    In the version 1.0.6 when you link (as I do often) all the volumes together, Phones, Monitor, Main, Master and you turn the knob left and right the volumes have completely unexpected behaviour: every one after some turns has his own value; even some of them go to zero and so on. Then you have maually, one to one, restore the initial settings you want.


    It seems as if the new idea behind the BUG was to link the volumes maintaining the relatives differences :wacko:
    (so, for example: if you set "Monitor Volume" to -10 and "Main Volume" to -5 and they are linked together, when you turn left "Master Volume" to -12, "Monitor Volume" automatically must become -17... but it doesn't work...). Does anyone can do some tests to see if it occurs only to me?


    Thank you!
    Maurizio