Let's discuss 11.0 Beta

  • Also locking the input locks the noise gate which I want to be variable.

    That’s a fair point.


    It doesn’t bother me personally as I set it as low as I can get away with and leave it there. I don’t mind a tiny bit of noise if I switchto an occasional super high gain sound but need it to not interfere with clean sounds regardless. I can understand how others may use a wider range of gains though. Modern metal players seem to use mega gain on the dirty sounds and ultra clean compressed (almost DI) sounds for clean stuff. That would probably need individual noise gate settings but I rarely use totally clean or gain on 11. I live in the middle ground and can get away with locking the noise gate.

  • Absolutely Nothing seems to make sense within the Kemper mindset. It's all too confusing for me and I have neither the time nor the inclination to figure it all out. Perhaps it's time to go back to using real amps?

    I have advocated to several people to switch from their tube amp rigs to a Kemper. Usually this is because they are amazed at the live sound I am able to achieve compared to their own live sound (several of them have played with me and could hear the Kemper vs their tube amp rigs first hand).

    That stated, Kemper is not for everyone. If you use little efx, are very cost sensitive, play primarily in your basement or just jam once in a while, etc, etc, then a decent tube amp rig might be the very best solution for you.

    Where I will absolutely defend my KPA rack and foot controller is in a frequent live gig use case, especially for a cover band where a wide breadth of tones need to be accomplished. Here the KPA reigns supreme IMO.

    I have also seen that it is very hard for people who are used to a specific rig's workflow to change. They know the amp, and their custom foot control board setup and have no desire to change.

    For me, lugging around a tube amp and a 4x12 cab along with a pedal board (and a guitar cab mic) was just way too much work and too inflexible for tone. You will never get a good Marshall sound out of a MESA triple rect or a Fender twin, but you can get all three easily from a Kemper ..... and it weighs only 11 lbs!

    There is nothing wrong with using real amps. Good lord knows I gigged tube amps myself for 30 years (1983 to 2013), and I didn't switch to Kemper in order to get good tone (actually I thought I would lose tone for sure). I switched due to load in/ load out/ and setup times along with reproducibility from gig to gig. The tone was a pleasant surprise.

    I would also state, that Kemper is by far the easiest, and most intuitive of the digital guitar amps to use. Still not as simple as a tube amp and pedal board perhaps, but a damn site more simple that 3 tube amps and a switcher :).

  • It's almost like I wrote this. Isn't it interesting how there are many types of Kemper users, some that want to hook it up to all kinds of weird software and different devices with a wireless remote and some that just use it for a pedal platform like a single channel amp. My point is there are a few people on this forum that see things almost exactly as I do, (mostly road dogs/ people that play out a lot). Some may argue and disagree but there are a few of us on here that I see fairly consistently agree with why they love their Kemper and why it's preferred over our Tube amps.

  • It's almost like I wrote this. Isn't it interesting how there are many types of Kemper users, some that want to hook it up to all kinds of weird software and different devices with a wireless remote and some that just use it for a pedal platform like a single channel amp. My point is there are a few people on this forum that see things almost exactly as I do, (mostly road dogs/ people that play out a lot). Some may argue and disagree but there are a few of us on here that I see fairly consistently agree with why they love their Kemper and why it's preferred over our Tube amps.

    Yea, I think the KPA is very popular among road dogs. I just love my KPA as a gigging rig. I have a 1 trip load in/load out, and can setup on stage in about 10 minutes..... and some of that is storing away my guitar case, KPA rack covers, and my gig bag that holds my remote and cables :).

    I figure I am set with the KPA until I am unable to gig live anymore (probably another 5-10 years as I am 58 now). I used to gig with 3 guitars (Taylor acoustic, fender strat and Gibson Les Paul). I now gig with 1 (and a spare) PRS Custom 24, use the split coil feature for my single coil sound (with specific rigs designed to make it sound more like a strat), and a couple of acoustic sim rigs to replace the need for my Taylor. For me, gig simplicity leads to gig consistency (should be a poet!).

    I don't have temperamental tube amps, fussy pedal boards with knobs that can be bumped and cables that can get messed up and big heavy cabs to lug around. Don't have to worry about a mic getting bumped away from the cab and messing up the live sound. Just lots and lots of things that are much easier now to get right gig after gig after gig.

    Still, the OP and others are right. The KPA isn't for everyone. Nothin wrong with the sound of a good tube amp and pedal board. Some people know how to make that rig work for them and don't want to bother learning how to do it any other way. My knees started giving me trouble in my early 40's and I really had to get my rig lighter and smaller (Ever carried an original VHT 4x12 cab and VHT Ultralead head before?). I also have a house with a walk out basement now so no more stairs for the PA gear either :). My knees are doing fine now.

  • Same here. I just played a festival gig and it was 10 minutes to set up

    I’m playin a outside gig Friday and it will be the same

    And it isn't just the gigs either. When I go to practice, the rig gets setup at the Lead Player's house for practice, broken down and brought home, and setup the next day in my basement.

    All those setups and tear-downs add up to LOTS of time saved over my old rig...... and quite honestly, I couldn't lug that big heavy crap around anymore without getting sore anyway. I like feeling good after a gig .... not like I got into a fight in a back alley and left in a dumpster :).

  • Some of these posts have nothing to do with the topic of 11.0 Beta.
    The same dilemma has been going on for over 10 years. Whether errors are discovered or not is purely coincidental. To date, there seem to be no test plans for the beta test that could be worked on. There are no official error lists so that errors can be confirmed or specified. From a QS manager's point of view, so much time and money is being wasted. If you assume a public beta test, all major errors should actually have been found and fixed internally.

    Be the force with you ;)

  • Some of these posts have nothing to do with the topic of 11.0 Beta.
    The same dilemma has been going on for over 10 years. Whether errors are discovered or not is purely coincidental. To date, there seem to be no test plans for the beta test that could be worked on. There are no official error lists so that errors can be confirmed or specified. From a QS manager's point of view, so much time and money is being wasted. If you assume a public beta test, all major errors should actually have been found and fixed internally.

    Not sure what you are saying here but Im pretty sure there is an error list, just not externally.

    And that makes sense to me as they internally test ( which is clear even in the Beta as I've had very few issues in any Beta) so not sure where you think time is lost.

  • Some of these posts have nothing to do with the topic of 11.0 Beta.
    The same dilemma has been going on for over 10 years. Whether errors are discovered or not is purely coincidental. To date, there seem to be no test plans for the beta test that could be worked on. There are no official error lists so that errors can be confirmed or specified. From a QS manager's point of view, so much time and money is being wasted. If you assume a public beta test, all major errors should actually have been found and fixed internally.

    Fair about the posts being off topic.

    Beta releases, by their very definition, are suspected to have some issues that the normal testing process can not economically identify. With complex engineering systems, it becomes impossible to exercise every potential path through the code with a real-world use case. This is what Beta testing is for. As for quality, the use of a beta release is a proven part of a quality process. Not certain what quality processes you are familiar with, but I can assure you that this is the case.

    I don't think that anyone should load a beta software on any device and expect that there are no issues with it.

    As far as the overall quality of the Kemper product, it is extemporary IMO..... and my opinion is coming from one who runs engineering departments for a living. On stage, this device has been rock solid through every release since I purchased it in 2013. From the forums here, there are very few (if any) stability issues, and within the main functionality, there are never any issues at all. The problems generally pop up in less frequent use paths and new functionality. This is normal.

    Furthermore, Kemper is very responsive to issues and feature requests and unlike other companies, doesn't require you to buy new hardware to get new features every few years.

  • Not sure what you are saying here but Im pretty sure there is an error list, just not externally.

    And that makes sense to me as they internally test ( which is clear even in the Beta as I've had very few issues in any Beta) so not sure where you think time is lost.

    To be specific:
    What open issues are there in this beta and what needs to be tested again to go forward? If everything is so easy and there are no more errors, why isn't it released?
    I think that in all beta releases, the known issues should always be listed in the release note. The last Beta updaste was in Jun ?!
    And in a post that is about this beta release, problems and progress on this release should be discussed and no personal statements.

    Be the force with you ;)

  • To be specific:
    What open issues are there in this beta and what needs to be tested again to go forward? If everything is so easy and there are no more errors, why isn't it released?
    I think that in all beta releases, the known issues should always be listed in the release note. The last Beta updaste was in Jun ?!
    And in a post that is about this beta release, problems and progress on this release should be discussed and no personal statements.

    If the last beta released was June, and today is mid July, how is that a problem? A month or two of beta testing is not excessive in my experience. If issues were found, then time must be added to fix and integrate.

    One of the issues with a single binary utilized over multiple hardware types is that more validation is required. It is offset by the single code base advantages, but as per my previous posts, "In engineering you never get something for nothing".

    Also, at this time, Kemper is very likely using much (if not all) of its firmware resources to bring the paid update to the Player to market. This represents a huge upgrade to Player owners and a new revenue stream for Kemper. If it were my company, all other matters would be taking a back seat to that work stream with very very few exceptions.

    I am not unsympathetic to your frustration though. All of us would like more free updates with more free features as soon as possible. We must all keep in mind that Kemper is a business and does all the work they do to create profit so they can continue to gainfully employ and expand their business. God forbid that our selfish desires for more new features be delayed by the companies need to continue to make payroll ;).

  • If the last beta released was June, and today is mid July, how is that a problem? A month or two of beta testing is not excessive in my experience. If issues were found, then time must be added to fix and integrate.

    One of the issues with a single binary utilized over multiple hardware types is that more validation is required. It is offset by the single code base advantages, but as per my previous posts, "In engineering you never get something for nothing".

    Also, at this time, Kemper is very likely using much (if not all) of its firmware resources to bring the paid update to the Player to market. This represents a huge upgrade to Player owners and a new revenue stream for Kemper. If it were my company, all other matters would be taking a back seat to that work stream with very very few exceptions.

    I am not unsympathetic to your frustration though. All of us would like more free updates with more free features as soon as possible. We must all keep in mind that Kemper is a business and does all the work they do to create profit so they can continue to gainfully employ and expand their business. God forbid that our selfish desires for more new features be delayed by the companies need to continue to make payroll ;).

    That's the best response I've seen in this post, Kemper should learn from you.:)

  • To be specific:
    What open issues are there in this beta and what needs to be tested again to go forward? If everything is so easy and there are no more errors, why isn't it released?
    I think that in all beta releases, the known issues should always be listed in the release note. The last Beta updaste was in Jun ?!
    And in a post that is about this beta release, problems and progress on this release should be discussed and no personal statements.

    I actually agree with their model.

    They test the best they can and then release as a Beta. As soon as a fault is identified they look to release another version with a fix.

    They don;t publish the known bugs I assume because:

    1) Im not sure they have a list and that they release what they think is a complete version but can't fully test all scenarios,

    2) They fix stuff so fast that keeping an up to date list would be difficult

    3) Publishing a list will "lead the witness" and so its often better to test blind rather than have a set list of bugs to distract people


  • The point here is to optimize the efficiency of testing. If everyone encounters the same errors, I don't need to test any further at this point. If I know that there is a problem with a certain function, I don't need to write another error report and if I know that someone has successfully tested a functionality, I don't need to do it again. Therefore, a test plan that naturally grows over time would be of great use.

    2) They fix stuff so fast that keeping an up to date list would be difficult

    Sorry but no! there are very old issues that are reported again and again for years.


    For example,
    I have noticed (and have reported this several times) that the display of numerical values is often inconsistent.
    Some values are in dB but also in 0-255 or 0-100%.
    In the system setup in particular, values for contrast or display brightness are sometimes shown in % and sometimes in integer.

    The irregular flashing of the TAP button seems to be impossible to control. since years.

    With AppleMac OSX, when it goes to sleep (Hybernate), the connection to the Kemper is disconnected after waking up and can only be restored by unplugging and re-plugging the USB cable.
    The MAC log says that the Rig Manager is generating an internal driver error. I have also reported this in previous versions but have not received any response so far.

    Be the force with you ;)

  • Just totally disagree.

    We are not testers, we are users. I'm not interested in testing but I take the betas to get early sight of functionality, knowing its already been tested pretty well.

    This is mixing up beta testing and the general issues...I didn't mean there are aren't bugs out there but I'm also not trying to test the whole platform.

    Most of the long term bugs, in my mind, are not showstoppers and therefore not a huge concern. I think publishing a list will just create unnecessary concerns.