Delay in other FX slots

Hopefully , when the editor will be release , we'll be able to put any effect in any order ....

The kemper team is well aware of this request and they have stated they are going to focus on improving delay. I have to imagine this is something theyll implement

This kind of feature would not require an editor.

As an aside to the OP, don't take it personally if you get no response to your question - they don't usually make timeline statements.

I think the sticking point is how to implement it without breaking the current feature set and signal flow. The Kemper team tends to come up with elegant solutions to what otherwise could be rather messy implementations. I imagine that this is what is causing the wait (aside from other higher prioritised features, of course. Did someone say spring reverb? )

Ps @ckemper said that Delay was number 2 in the queue in a thread a while back

Yup, I think You hit the head on the nail Sam.
If we think about it, delay and reverb are quite different fx from the rest on the KPA. Since they are able to keep on processing the sound even after then have been turned of or changed to a new preset. (spillover!)
My guess it that this is why they have their dedicated slots, and to place a delay or reverb in ANY slot with the same features requires a total overhaul of the fx subsystem.
And when you're doing that You are faced with big decisions: How far can we go? How much will it cost (in KPA resources)? How do You implement it so it will be usable for a non engineer? Backwards compatibility? And so on...

Quote from JeffTD

I think you guys are seriously overcomplicating the issue but I don't care to get into that argument here.

@sambrox - @ckemper has said that delay number 2 in the queue, but what about delay is at #2? Adding more delay types or freely routing the fx blocks?

I dunno, he just said that in the context of feature requests and effects, delay was number 2 in the queue. I don't know what he meant by that specifically, other than they are going to look at overhauling it. They don't do things by half in my experience, so I'm expecting something unexpected, haha!

I am just guessing here, but, I believe that the implementation of the Floor controller, Pure Cab and a few other upgrades have caused more support issues than Kemper had envisioned. Even the latest release doesn't appear to be flawless - although I have no personal experience with it.

If it were me, I wouldn't further confuse the code-base troubleshooting with another major release until I had worked ALL of the existing bugs out. It would seem to be much more difficult to track down the offending code with another big change piled on top of existing code that has a few issues.

Finally, with winter NAMM just around the corner, I would wait so that I would have something new to show.

Agreed I'd rather see all the bugs ironed out, everything exactly as it should be, then move on.

If it really is stuff like spill over causing a problem then how about we have the delay section still fixed in the delay module, but also have a simplified (if needs be) stomp delay that can be put anywhere in the chain.

That way we could simulate a analogue delay in front of the preamp, or chain together multiple delays, which are the two things I would imagine most people would want a stomp delay for.

Quote from JeffTD

Bug fixes and feature development absolutely do not have to happen independently of each other and are not mutually exclusive. A lot of the comments in the thread are derailing the request with hairbrained/whimsical ideas of how some people think development works.

I can promise you this:

There will never be a point in time at which there are no bugs. Fixing ALL the bugs is just not a thing that happens - there are and there absolutely will be more bugs that never, ever get fixed. There will even be some bugs that never, ever get looked at or even remotely prioritized; the notion that Kemper & co should wait until all the bugs are ironed out before working on anything else is as ignorant as it is asinine.

I bet you are loads of fun at a party.

Quote from JeffTD

Bug fixes and feature development absolutely do not have to happen independently of each other and are not mutually exclusive. A lot of the comments in the thread are derailing the request with hairbrained/whimsical ideas of how some people think development works.

I can promise you this:

There will never be a point in time at which there are no bugs. Fixing ALL the bugs is just not a thing that happens - there are and there absolutely will be more bugs that never, ever get fixed. There will even be some bugs that never, ever get looked at or even remotely prioritized; the notion that Kemper & co should wait until all the bugs are ironed out before working on anything else is as ignorant as it is asinine.

As a web developer myself, I totally understand. For those outside that bubble, here's how a typical development process works (techniques and nomenclature vary, but this is more or less how it works):

1. You have the current code. It's called "master." Master is the current production code, or the most recent release.
2. You have hotfixes, which are, at least when using semantic versioning (major.minor.patch for version numbers), your patches. These branch off of master, and their code is merged back in when deemed acceptable. These are typically bug fixes.
3. You have features, which are features being worked on. For example, with the Kemper, there may be a feature branch of code for a delay improvement, one for spring reverb, one for some yet-to-be-named feature, etc. These branch off master, and are eventually merged into #4.
4. You have releases, which are a set of features (and sometimes bug fixes as well). A release is a combination of one or more completed features, and typically result in a minor version update (3.1.X to 3.2.0, for instance).
5. And, finally, you have Epics. Epics typically result in a major version update, and are a combination of many different features that represent a bigger thing. For instance, Kemper OS 3.0 brought in new profiling methods. I guarantee Kemper was working on these since 2.0. These result in a major version update (2.X to 3.0, for instance).

Because of the beauty of modern technology, one developer can be writing a bug fix for something, two other developers can be working on a new feature simultaneously on separate machines, and a final developer can be improving a function already on master. As things get done and can be run through quality control and testing, all of the code that is released is merged back into a release. All branches of code stay up to date, and any bugs found and patched are applied to anything outstanding. This is not sharing a Word document on Dropbox. This is sharing code across networks, with a running database of what has changed, what's been added, and what's been removed. Everyone stays in sync, regardless how far they differ from each other on what they're working on.

However, when you do add new features, bugs are prone to rear their ugly head more often. Why? Because you made an internal change to the way the software works. Think about writing a long, detailed email to your boss. If you forget something, you can throw a paragraph right in the middle of your email. But that next paragraph may not make sense. You need to go back, re-read it, and make changes. Maybe move that paragraph to the end instead? Or maybe the beginning? Now, imagine that with hundreds of thousands of lines of assembly/machine code (this is hardcore programming right here, used for performance, speed, and file size), and imagine the possibilities that one update can make on the entire infrastructure of the Kemper software, especially when it's not as legible as a more modern programming language.

Jeff's absolutely right. Code, regardless how much it's tested and run through quality assurance, will never be 100% bug proof. It may be code running on a machine, but that code is written by humans, and those machine parts are designed by humans. You can't possibly keep every single line of code, every chip specification, every state of a button, every state of the screen, every internal library and API, etc. in your head, and sometimes something just gets missed. Sometimes things cause abnormal things to happen that are completely unexpected because there's a weird conflict. Look at similar players in the industry - Line 6, Eleven, Fractal... their software all has bugs. And it gets kind of scary when you think about more complex things like life support machines and self-driving vehicles - they operate based on code written and developed by humans. Who aren't perfect.

Quote from JeffTD

Thanks for explaining that one way more eloquently than I have patience for!

Even a cursory understanding of VCS or Git would be hugely beneficial for anyone who uses software. People have this crazy idea about code being a huge pile that gets added to all the time... not the case. It's more like a ton of pallets that get carefully and constantly stacked and re-stacked, only its really easy to open up one of those pallets and change what's inside without ruining (or even touching) the rest of the shipping container.

When I graduated college (2007, I have a BS BS (yep, haha) in information systems, with a focus on software development), there was never a mention of Git, Subversion, Mercurial, VCS... none of it. I can't imagine developing without Git these days, even if I'm just developing a project solo. That was only 8 years ago. And what was taught then was simply, when working with teams, just share files or lines of code via IM or email. I can totally understand why the normal consumer doesn't get this stuff if it wasn't even taught in undergraduate, specialty-focused programming courses.

@JeffTD I don't think anybody is derailing your feature request by discussing theories of why the Stomp Delay hasn't been introduced yet. The Kemper team doesn't strike me as being a unit that looks at these requests then thinks, "well, I was going to start looking at the delay, but it it seems folks are happy to wait a bit longer until we've done x and ironed out the bugs of y first". Of course, you're right about coding and new feature sets being independent of bug fixes, and the manual that came with my first KPA 3 years ago describes the Stomp Delay, so I think it's something that is ongoing, regardless. Again, we can only speculate as to the reasons why it's taken so long.

Agreed with a lot of points here, I'm a firmware developer by day and we certainly have releases that focus solely on bug fixes rather than adding new features, it's not that an unusual thing in my experience.