Let's discuss 11.0 Beta

Ok, I concede that your reply was most eloquently stated and makes a lot of sense. Iv'e figured out a few things since my initial frustrated outburst. As such, I apologize to all for any offense caused.

Quote from V8guitar

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.

So what do you think a public BETA is?
On one hand, Kemper says not to use it in productive environments or production.
You say you're not a tester, and not interested in testing.
So what do you do with it?
In my humble opinion, I would never ever use a BETA on stage, in rehearsals, or in the studio.
I don't have the time to flick around and hope I don't run into a bug.

I'd like to know what I'm dealing with, and where bugs are still hidden.

Quote from Yoda Guitar

So what do you think a public BETA is?
On one hand, Kemper says not to use it in productive environments or production.
You say you're not a tester, and not interested in testing.
So what do you do with it?
In my humble opinion, I would never ever use a BETA on stage, in rehearsals, or in the studio.
I don't have the time to flick around and hope I don't run into a bug.

I'd like to know what I'm dealing with, and where bugs are still hidden.

What a public beta is ‘supposed’ to be and how they’re actually viewed and used by the larger public have little in common.

Most people don’t treat public Betas of anything as little more than a chance to get the latest and greatest…..with a twinge of risk. Most never report issues.

If you’re earning all or part of your living with it….running betas is asking for trouble.

That’s common sense and irresponsible to do otherwise.

Quote from Yoda Guitar

So what do you think a public BETA is?
On one hand, Kemper says not to use it in productive environments or production.
You say you're not a tester, and not interested in testing.
So what do you do with it?
In my humble opinion, I would never ever use a BETA on stage, in rehearsals, or in the studio.
I don't have the time to flick around and hope I don't run into a bug.

I'd like to know what I'm dealing with, and where bugs are still hidden.

Its a release of software that has been internally tested but given you can;t capture everything in on a test bench, its released as a Beta so that users are aware of this. Its an extremely sensible way to release complex software.

I'm not testing it, I'm just using it as normal. The difference is I don;t systematically go looking for issues as a tester would, I don't run test scripts nor do I look to break it. I run a software development team which includes a test function so I'm pretty familiar with the differences.

I do use Betas on stage because:

1) The chances of any catastrophic issue is very low, if any bugs get through they are low level. The risk of a catastrophic issue in Beta vs full release is not that different so I think its low risk.

2) I only play pub gigs and so any small bugs are not really going to hurt and I carry a backup.

3) Never had a problem so far, showing that their testing is pretty good. I've had no bugs in beta that made the KPA unusable

But that is why they tell us its a beta so you can choose and I understand why many people don;t use Beta's and prefer to wait for the full release. This is definitely sensible and Im probably a bit too reckless in that sense. I have had issues live but they were not related to Beta releases.

BTW there is always the risk that bugs are not picked up in Beta release as well so no guarantees here, its all just about risk.

Quote from Yoda Guitar

So what do you think a public BETA is?
On one hand, Kemper says not to use it in productive environments or production.
You say you're not a tester, and not interested in testing.
So what do you do with it?
In my humble opinion, I would never ever use a BETA on stage, in rehearsals, or in the studio.
I don't have the time to flick around and hope I don't run into a bug.

I'd like to know what I'm dealing with, and where bugs are still hidden.

A beta is to be used with the explicit understanding that it may not be stable, may have issues that have not been documented, and may have featured that don't work right.

People only use them to get an early look at features that aren't in the production release yet. Some people love these features so much they are willing to take the risk of using the beta for a paying gig. Others ..... not so much.

The fact that Kemper has "bugs" that have been around for a very long time is nothing to fret about either. None of the "bugs" are deemed "CRITICAL" in nature (nor were your examples).

Kemper will want people to report issues individually even IF others have reported it. A single report of a glitch is NOT worth spending any engineering time on while a repeated issue by a decent percentage of users is.

People also tend to mix up "bug" with "undesirable behavior" or even "missing function".

Kemper is an amazingly complex device. I can't even fathom how many potential validation paths must exist in order to test every single possible workflow. Considering this, Kemper does an outstanding job IMO of making a VERY stable product.

Plus, keep in mind that if Kemper weren't continuously adding new free functions to the KPA, the device would have already been given it's final firmware upgrade YEARS AGO and would be perfectly stable with no bugs left at all.

I suspect that the last version of firmware for the AxeII FX is quite stable ...... and completely obsolete. My VHT never had a single "bug" :). Those of us that want the capabilities and continued enhancements from a digital amp, must be willing to take the good (11lbs for a bizzillion amps and efx) with the bad (sometimes bugs are introduced or things we want changed or fixed don't get the attention we would like).

Quote from OneEng1

The fact that Kemper has "bugs" that have been around for a very long time is nothing to fret about either. None of the "bugs" are deemed "CRITICAL" in nature (nor were your examples).

Plus, keep in mind that if Kemper weren't continuously adding new free functions to the KPA, the device would have already been given it's final firmware upgrade YEARS AGO and would be perfectly stable with no bugs left at all.

The problem is that some bugs are not present in older versions, but have only appeared due to new functions. E.g. in studio use, the KPA USB connection problem means that I have to continue using version 8.7. The error is demonstrably repeatable and is also documented in the internal Rigmanager log. I have reported this situation to the support team several times, but have not yet received a satisfactory response.
However, Kemper always mixes updates with upgrades, bug fixing and the introduction of new features.
So anyone (like me) who hopes that errors will be fixed will always be disappointed that although some errors are fixed, and new errors arise. I would prefer a stable version that is as error-free as possible instead of new functions.

Quote from Yoda Guitar

The problem is that some bugs are not present in older versions, but have only appeared due to new functions. E.g. in studio use, the KPA USB connection problem means that I have to continue using version 8.7. The error is demonstrably repeatable and is also documented in the internal Rigmanager log. I have reported this situation to the support team several times, but have not yet received a satisfactory response.
However, Kemper always mixes updates with upgrades, bug fixing and the introduction of new features.
So anyone (like me) who hopes that errors will be fixed will always be disappointed that although some errors are fixed, and new errors arise. I would prefer a stable version that is as error-free as possible instead of new functions.

You are describing a number of issues here.

In regards to new bugs, I have no idea what your experience of software development is but you describe a utopia that will never exist. Any change, including fixing a bug can introduce more bugs. So even if Kemper stood still and just fixed bugs, there would still be some bugs. Its the law of diminishing returns, you then spend so much time and money chasing bugs that have little impact to the majority - this is the prioritisation.

Its not unusual ( sorry, can't say that without thinking of Tom Jones) to release features and bug fixes. Each release costs time and money so combining to 2 is more effective and fairly normal.

No software is ever bug or error free. That is because even in the field, new scenarios that have never been used before, let alone tested, will show unexpected results. However, I think the KPA is very stable, I've had no major software issues int he 10 years I've had it. The software releases are free, regular and provide fixes to many issues experienced as well as features.

As a result I think Kemper has the model right, we get new features and bug fixes (based upon seriousness) ASAP. The downside is that yes there are some longstanding bugs that for some people are an issue but for the majority are not ( and they use this forum to assess that).

Quote from Yoda Guitar

The problem is that some bugs are not present in older versions, but have only appeared due to new functions. E.g. in studio use, the KPA USB connection problem means that I have to continue using version 8.7. The error is demonstrably repeatable and is also documented in the internal Rigmanager log. I have reported this situation to the support team several times, but have not yet received a satisfactory response.
However, Kemper always mixes updates with upgrades, bug fixing and the introduction of new features.
So anyone (like me) who hopes that errors will be fixed will always be disappointed that although some errors are fixed, and new errors arise. I would prefer a stable version that is as error-free as possible instead of new functions.

With rare exceptions, every device on the planet mixes new features with bug fixes in nearly every release (when new features are being worked on).

Once new features are off the table for a product, it is usually not long before updates cease to be released at all. The product is brought to an end of life stable (as stable as the decide to get it) state, and all internal development efforts are shifted to new programs.

I think that the Kemper has been incredibly stable for live use; however, based on your comments and others, studio use has been lagging. IIRC, the USB studio interface was just introduced not that long ago, and even the Rig Manager (with its full device integration and editing) is pretty new compared to the unit itself.

I jumped on board in 2013 shortly after performances were first introduced. Performance mode and live performance has been my main workflow almost exclusively. I recall an endless line of threads from studio users complaining that it was unconscionable that the Kemper did not include a USB recording interface. I also recall lots of threads on the optical interface IIRC.

It seems clear to me that the KPA design targets were prioritized for live sound usage first, and then later shifted to studio users. I am pretty certain that this was done intentionally as the Fractal camp has a ridiculously complete studio interface and GUI (ie, you don't attack a competitor at their strength, but at their weakness).

I think that the KPA will be honed into a decent studio tool; however, it seems clear to me that the products greatest strength is in live performance where it reigns supreme IMO.

Did support get back to you? I have gotten pretty quick responses from them when I contacted them in the past.

Quote from OneEng1

Did support get back to you? I have gotten pretty quick responses from them when I contacted them in the past.

Yes, that is ticket number 323886.
Nobody expects a completely error-free version,
but I expect known problems to be fixed, especially if the functionality worked in older versions and especially if the error is reproducible and repeatable.

I have been working in IT for over 30 years, specializing in large databases and trading systems in investment banking. Here, a clear distinction is made between error correction and function expansion. And there is always a maintenance update or bugfix release before new functions are introduced.

So tis Beta 11.0 is a maintenance release i guess.

Quote from Yoda Guitar

large databases and trading systems in investment banking.

Wow - I suppose that defects in that type of systems are often critical, with risk of huge amounts of money lost on deals not going through correctly and the like?

Quote from Yoda Guitar

Yes, that is ticket number 323886.
Nobody expects a completely error-free version,
but I expect known problems to be fixed, especially if the functionality worked in older versions and especially if the error is reproducible and repeatable.

I have been working in IT for over 30 years, specializing in large databases and trading systems in investment banking. Here, a clear distinction is made between error correction and function expansion. And there is always a maintenance update or bugfix release before new functions are introduced.

So tis Beta 11.0 is a maintenance release i guess.

I hear you.

Every issue tracking system in existence has a "Severity" field associated with every issue. If very few people report a specific problem, or if the problem is not seriously preventing the use of the system, then the issue will get shuffled to the end of priority list (note that also most issues have a "Priority" field that is generally assigned by the Scrum Master for the project (or project manager).

I have been in charge of some pretty big software programs (GM global service tools launch as an example). It was fully 2 years into the program before we got down the severity list to the "Medium" priorities. The "LOW" are likely still not addressed over a decade later.

In production critical software (like a manufacturing test system for a global vehicle OEM), there are (as you pointed out) some scheduled releases that are JUST bug fixes for stability and critical functionality. HOWEVER, in these systems, the time between new functionality releases is MUCH higher because of the critical nature of the software and the terrible price of an issue if it is released. The roll out process for this kind of software is also much more complex than just "Beta" and "Production" and takes much longer to do as well.

Kemper software is certainly not this level of software. Based on my many decades of development experience (from a developer myself, to being a C-Suite engineering executive), it seems to me that Kemper's release process is quite good for the product category they are in, and in comparison to their industry competitors processes.

Having said all this, I suspect that the delay in fixing your specific issue is none of the above at all, but rather the fact that Kemper is likely resource limited and are heads down trying to get the Kemper Player paid update released. Once this is taken care of, I suspect they will get back to cleaning up the stray issues that are high priority that have popped up while the team was busy.

I have had strategy meetings with my program managers outlining strategies to use to deal with the list of customers I was intentionally putting on the back burner while we worked on a critically strategic initiative that sucked up resources from many other programs throughout its duration. There were just going to be some unhappy customers somewhere, but decisions like this need to be made for the health of the company. It isn't a forever problem, but rather a transient issue.

Quote from Yoda Guitar

Yes, that is ticket number 323886.
Nobody expects a completely error-free version,
but I expect known problems to be fixed, especially if the functionality worked in older versions and especially if the error is reproducible and repeatable.

I have been working in IT for over 30 years, specializing in large databases and trading systems in investment banking. Here, a clear distinction is made between error correction and function expansion. And there is always a maintenance update or bugfix release before new functions are introduced.

So tis Beta 11.0 is a maintenance release i guess.

Having worked myself for 28 years in software development in different industries, there is of course difference in criticality. Error free was the target for Aerospace and so yes prior to new functionality but less important for booking appointments for an Opticians.

I also hear you, just trying to add the reality here of the scale and size of the organisation and criticality of these issues.

Clean sense allows you to set the profiler so when you turn the gain up, you can tell the profile volume to go up, down or stay the same volume. Same for turning down the gain, you can make it raise, lower or stay the same throughout the gain range. (As I have wrote on here a million times, the Kemper video of this explains it perfect) So how does the new clean compensation differ from that? From what I have read in the handbook, it seems to do the same thing (allow you to adjust the way volume responds to gain changes) So what is different about the two?

Quote from Dynochrome

Clean sense allows you to set the profiler so when you turn the gain up, you can tell the profile volume to go up, down or stay the same volume. Same for turning down the gain, you can make it raise, lower or stay the same throughout the gain range. (As I have wrote on here a million times, the Kemper video of this explains it perfect) So how does the new clean compensation differ from that? From what I have read in the handbook, it seems to do the same thing (allow you to adjust the way volume responds to gain changes) So what is different about the two?

So they solve two different issues. One is about how the rig is constructed, the other about dealing with how a rig reacts to different guitars.

Quote

Clean Compensation
When Clean Compensation is set to maximum, the natural loss of volume of the amp PROFILE is compensated as the amp gain is dialed towards clean sounds. Amp volume is simply increased with decreasing gain settings, without further coloration of the sound. This reduces the need to re-level clean sounds for live performances. Most PROFILEs have Clean Compensation set to maximum.

By reducing Clean Compensation, you can lower the compensation to zero to achieve a natural gain behavior. This is recommended when using a distortion effect in front of an amp, and you’re aiming for that classic boost effect when engaging the distortion.

- from the manual

Quote

Clean Sens
Different types of guitars produce different output levels depending on their pickups and string gauge: for example,
humbucker pickups generate higher voltages compared to single coils, and active guitars generate even hotter
signal levels. If you feel that clean sounds are either very loud or very soft compared to distorted sounds, you can
adjust Clean Sens to a level where clean sounds have the same perceived loudness as distorted sounds. Clean
Sens determines the volume of clean sounds, but not the way that the amp or the effects are driven. A guitar with
low output level stays cleaner; a hot guitar will still distort more easily.

- from the manual

Display More

Quote from Ruefus

the other about dealing with how a rig reacts to different guitars.

This is what a lot of people believe because of how this is written in the manual. The way this was written there blurs the facts from my statement that Clean sense simply allows you to set the profiler so when you turn the gain up, you can tell the profile volume to go up, down or stay the same volume. Same for turning down the gain, you can make it raise, lower or stay the same throughout the gain range. I implore you to watch the video that explains this and you'll see why the way the manual is written (IMO) creates some confusion to what clean sense does. It's not really about how different guitars react, it's about what happens when you raise or lower the gain volume wise. Again, please watch the video.

Quote from spotter

To put it in the words of the Duke Nukem-developers: "It's done when it's done."

And look how well that turned out...

Even after watching all available videos and endless tinkering I was never able to configure "clean sense" to actually get softer when I back off volume on the guitar. However, the Beta 11 code actually does support this when "clean compensation" is dialed to minimum. I no longer feel like I'm fighting with the volume leveling.

Quote from vtgearhead

Even after watching all available videos and endless tinkering I was never able to configure "clean sense" to actually get softer when I back off volume on the guitar. However, the Beta 11 code actually does support this when "clean compensation" is dialed to minimum. I no longer feel like I'm fighting with the volume leveling.

That's because clean sense adjusts what the volume of the Rig does when you turn up/down the GAIN, not volume of the guitar.

Would be nice to here more from Kemper what they thought is “clean compensation”. They know how it is programmed and how we should use it in contrast or addition to clean sens.

They recommend it to change the behaviour of distortion Paddels in front of the amp