Is everyone now on 4.0.6?

    Quote from G String

    sorry, if this came out wrong - i wasn't intending to sound brush.


    You didn't sound like a brush at all, mate; that would've been more abrasive (hint, G String - I know you meant "brash").


    Thank you for clearing that up, mate. You had us worried!

    Thank you for taking the time to respond, I know you are busy, and I thank you,,
    I never took it as harsh,, again,, I am not mad, just want 3 to work like 4, system wise,,no lag,display or other wise,
    so I can continue on the kempertrain,,was never mad,, just a little surprised,, but not mad,We are after all only human,,
    mayby" hinting" is not the way to go,, just a thought,,,I come here for help, facts and good advice,
    I did take your advice, I am still on 3, I bought am amp I love, so, like I said,, I am waiting,
    I was hoping for a response like,,,, "we are working on it and hope to have it resolved soon, we want our devise to work perfectlywith all operating systems.and understand you concerns"
    that would have gone a long way, just to know they know, and are concernd about getting it right, but I never got that vibe from the response,
    like the great man said,
    "You cant always get what you want," I still love my kempers,,would not step into the studio without it,
    I am waiting ....
    http://www.mariomassi.com

    OK I know I'm jumping in I midway here, but it kinda sounds like you're seeing the different numbers for the Kemper as actually different operating systems with their own support and service updates like Windows 7 vs Windows 8. They're not. They're just incremental versions of the same OS, I.e. Bug fixes and the odd feature here and there. The jumps in numbering just relate to bigger features being added rather than a change in architecture, and certainly no change in sound.m it's all really incremental, once you run out of revisions under 3.00 you gotta move up to 4.00 (internally you can end up with a lot of revisions even if you only increment for beta testers, it's easy to go through 99 versions).


    So don't really take the version number into account when considering upgrades, instead just look at the features. You can't have 3 work like 4, because that's what 4 is. it's just an ever forward moving thing.

    Quote from Per

    OK I know I'm jumping in I midway here, but it kinda sounds like you're seeing the different numbers for the Kemper as actually different operating systems with their own support and service updates like Windows 7 vs Windows 8. They're not. They're just incremental versions of the same OS, I.e. Bug fixes and the odd feature here and there. The jumps in numbering just relate to bigger features being added rather than a change in architecture, and certainly no change in sound.m it's all really incremental, once you run out of revisions under 3.00 you gotta move up to 4.00 (internally you can end up with a lot of revisions even if you only increment for beta testers, it's easy to go through 99 versions).


    So don't really take the version number into account when considering upgrades, instead just look at the features. You can't have 3 work like 4, because that's what 4 is. it's just an ever forward moving thing.


    It is only my SWAG (Sophisticated, Wild A$$ Guess) that 4.x was an architecture change based on how I have interpreted how the Kemper firmware must be written in order to do what it does.


    As an example, having the general ability to hook up multiple variables, and just about ANY variable in the device, to a sweep of an analog input would be most easily done IMO by changing the underlying base class structure (if done in c++), or by modifying the basic struct clauses if in straight C. If the Kemper is well written, then all interfaces would deal with a base type that could be modified in an abstract manner to keep the code base tight.


    Changing the basic class structure of a program is much like modifying the foundation of a building. You have to lift everything up, modify the foundation, then make the top meet with the bottom through a series of modifications to the top, then lower the top back down onto the modified foundation ;)


    IMO, making the delay have the ability to be assigned to any slot was likely still an architecture change, but it was much more limited in scope .... and therefore much less risky. Still, as we know from the beta test, there were still several issues caused by the change that took a bit of massaging to get right.


    Adding new verbs and new delays should be much less invasive IMO.


    G String,


    Thanks for clarifying your post.

    I'm afraid that we'll never know what kinds of changes were involved in implementing morphs for 4.00. They could have been trivial or they could have been extremely complex, we don't even know what language Christopher and his team use. However it's a UI change. Unless this is hard coded right into each element, function and page (which seems unlikely given the consistency), then this should not be a complex or far reaching (in terms of code change) task. And my gut instinct says this was just one of those fun things you add because you can see an easy way to make something cool.


    Regardless Kemper have never indicated that there is any OS series, e.g. 3 or 4, nor offered updates for older versions (except when it's converting an existing prior build to Release status while a new beta is going on), they've instead always intimated that it's just continuous updates. There is the latest version, then there are legacy OS versions.

    Quote from Eltzejupp

    It must be a big change in the database. Did you see that the size of a backup is much bigger than under 3.xx?


    My impression is similar. (For me OneEng1 has described it very good.)
    As retired technician with lot of IT background I can also only guess, what is the basic language.
    A change of the datebase in this dimension (almost double) and the need that the system has to work continuosly is a huge step.
    Even if no functional modifications would be achieved. And there are some functional enhancement in the new Version.
    For me it was a remarkable achievement with small but rather unimportant problems.
    I always had a System for playing gigs and I did not shy the risk using always the last beta. (OK I do not use the KPA as professional but this does not detract the performance of Kemper.)
    It could be that still some problems are left to be solved before a functional improvement (e.g. reverbs) could be released.
    I am pretty sure they already work on it.

    Ionno, increase in fileformat don't indicate much to me beyond additional parameters being stored. A doubling of data size doesn't equate to a doubling of program size.


    In this case I suspect that rather than storing a separate morph block (or table if you want to think of it in database terms) with just the parameter deltas affected and corresponding element id's they're instead storing a delta/second value for each float/int UI parameter (and maybe even a boolean used state), so if that were the case then it makes total sense that it would close to double.

    Quote from Per

    Fair enough but then I'm confused because I don't really get what the filesize has to do with 'ought?


    Just a sign, that the database was changed.
    The amount of changed or added datas needs not to be proportional to the a structure change.
    But anyway - I think it is senseless to guess how difficult is was.
    Fact is that this modification seemed to took longer as promised and maybe expected.
    For me a pretty normal occurrence in a development. It is not every time possible to estimated the efforts in advance.

    Quote from Sharry


    Just a sign, that the database was changed.
    The amount of changed or added datas needs not to be proportional to the a structure change.
    But anyway - I think it is senseless to guess how difficult is was.
    Fact is that this modification seemed to took longer as promised and maybe expected.
    For me a pretty normal occurrence in a development. It is not every time possible to estimated the efforts in advance.


    That has been my experience as well ;) Things always take longer than you expect in engineering. Even simple code changes in a complex system can have side effects that no one could have predicted.


    IMO, the morphing feature, being implemented in as broad a way is it is, was quite a big rip-up. If all they had to do was make it so that you could sweep the gain, this would have been pretty easy.


    Back on topic.... ;)


    I will likely wait until the new verbs and/or delays become available. I am pretty happy with 3.3 right now.

    I really want to upgrade to 4.0.6 but I have one concern: I use a Behringer FCB1010 with a Eureka prom chip for patch switching. I'm worried that if I upgrade, it might render the Eureka prom chip useless. Does anyone else use the FCB1010 with the chip who can confirm whether it's affected by the firmware upgrade or not? Thanks guys.