Posts by heldal

    I share other's concerns about an editor that relies on a usb connection.

    USB doesn't have to cause such problems. I've got other types of gear which functionality never has been impeded by anything connected to its USB-port. What I fear is that the problem is at driver-level which puts a fix out of reach of CK and his team. I believe the KPA is based on some minimalist, preferably real-time, operating-system which would be responsible for handling networking/USB I/O. A network-scan I did some time ago by hooking the network-port to my LAN was unable to clearly identify the system, but the exposed part of the network protocol-stack was pointing to some form of Windows. You'd need internal knowledge of the design to be certain.


    That said, I think we should drop the bug-discussion from this thread. My point was only to emphasise that I wish CK and his team are able to solve this issue with a firmware-update accompanying the editor when it finally arrive. A failure to do so makes the KPA/editor combo a lot less desirable for uses where the editor will be left idle, but remain connected, for longer periods of time.

    of course, because we don't even know about such an issue.

    I filed a ticket way back when I first encountered the problem which there never was much feedback for. I've had my KPA since before the first RM was released so I guess that ticket should date sometime within the first month after RM was introduced. Then again more recently (ticket #KA00168926). I even received tweaked firmware for testing last June, but it unfortunately behaved just like before. I sent a description on how I reliably can reproduce the issue within an hour or two, since then I have only used RM briefly to pull a few rigs from the exchange. I submitted another question to the forum to check whether others with different types of computers have the same problems as I do with my Macbook and got confirmations from windows users too. On June 20th I got a follow-up mail with request for further logs which were promptly submitted, but nothing since. I do occasionally test some beta software, but only when I do have the time. Music is a hobby, and I prioritise practise and gigging. I make my living as a software/network engineer, but have no wish to run a software lab in my spare time. I do follow up when I get direct questions about KPA stuff, but mostly I just want to turn it on, play and switch off.


    Don't get me wrong. I love my KPA, and even RM when it is used interactively to organise stuff and pull info from the exchange. It is only in a setting where RM may be sitting more or less idle for longer periods of time that the problem occur (recording/rehearsal). Still, it should not be necessary to always have to take care to disconnect the USB-cable from the KPA as soon as you're done with whatever you had to do in RM. It is so annoying during recording or rehearsal when the remote becomes unresponsive and goes into its boot-loop while the KPA gets stuck while playing. Granted, the unit normally keeps on making sound for the rest of the song, but all internal (knobs/buttons) and external controls (switches/exp-pedals) are non-functional until RM is disconnected or the KPA rebooted.


    My worry for the editor is that it will be based on the same USB-communications as RM that I'm quite certain is the source of the problem. The KPA can not protect itself from connected gear/software that deliberately abuse functions offered by the KPA, but a malfunction/anomaly in any piece of gear attached to the KPA should not be allowed to affect its function, performance or reliability. If this problem boils down to an unresponsive USB-peer it is still a failure on the KPAs part. Any attempt to send or receive information on the USB-interface must be required to complete within a defined number of milliseconds. If not, then the operation must be aborted.

    I'd much rather have CK and his team make the software, both KPA firmware and RM/editor, rock solid than getting an early bug-ridden release. RM has always been, and still is, a total PITA. One simply can not leave a computer hooked up to the unit for any longer period of time, which for many studio/recording guys is totally unacceptable. One has to be able to keep the KPA available as an audio-resource on a shelf like any other audio-processing-unit without wondering if or when it is going to lock up. It is not the first piece of gear I've had with problems, but the first where something as serious as system lockup doesn't seem to be taken seriously by its developers. It's been going on for years across countless firmware-releases. If it is as hardware issue that makes it un-fixable, be honest about it and inform the customers. I just pray this gets fixed with the new software, but I'm not holding my breath.

    I don't think hardware upgrade-ability is a viable long-term goal. Nobody knows which innovations the future will bring other than that we know the world is moving forward. Software OHOH is a different animal with a constant stream of fixes and enhancements, some of which gradually add to system load. My wish is is that manufacturers use a bit more powerful components when they design their gear. While the DSP and converters on the KPA still deliver excellent sound the system in general gets slower with every release with certain operations now starting to challenge my patience. There were more powerful components available back when the KPA was designed, at not so very much higher prices. $10-15 more in components back then would have made a huge difference today. We should expect better performing components in premium-priced high-end gear. The challenge here is to keep the beancounters at bay during the design-phase.

    I love my toaster, but I am completely with you wrt the physical design issues for the stage-model. The Kemper-stage as is would never work for me. Its flimsy unprotected controls wouldn't last a week. The guts of a Kemper head or rack would almost fit inside the old Kemper remote. That with controls from a tablet/phone via USB, bluetooth or network (wired+wireless Ethernet) would make more sense, and leave a much more robust floor-unit.


    With OS7 and its new approach to FX-presets and rig-selection the KPA will be easier to configure from it's front-panel than most of its competitors. I do therefore understand why Kemper has put so much effort into the physical interface. That said, in this time and age there is really no excuse for not offering a full-featured remote-control-application ... multi-platform even (ios/android/windows/macos). Multiple windows with drag-n-drop of effects from slots in one rig to another. Drag and drop from collections of presets. GUI's do offer a lot of opportunities a physical interfaces can not. Who wants to bend over a floor unit for hours while setting it up? Nearly all of those I know who use the KPA in studios would prefer to stack the unit(s) somewhere out of sight with remote-control.

    Your request may be a totally reasonable one but without an example I can understand why Kemper might not see the need to implement it as they won't understand who else might want to use it.

    I'll bite ;) Most of the time I use morph for solo boost (with or without added effects). For this use the default 2s is really too slow. To me a default of somewhere between 0.5s and 1s makes more sense. I do not want it to be a global fixed setting, but a variable default. When changed, the default should affect all rigs and performance/slots that have a value corresponding to the previous default while all other rigs (where rise and/or fall has been deliberately altered) remain unchanged ... or even better implement a flag for changed rise/fall for each rig that is stored as an indication of whether the parameters have been manually altered.

    For me it rarely requires a restart. Just pulling the USB is usually enough to get the KPA and remote working normally. That said, I agree it should be fixed. I submitted a ticket a couple years ago that either was lost/forgotten or nothing happened with, and recently filed another that now is in progress. To me the problem seems related to how USB works on the Mac when the screensaver and/or hibernation kicks in. The KPA can not protect against hostile attached devices maliciously exploiting some protocol, but a non-responsive attached device should never be allowed to block the KPAs operation. Any communications with external devices must be implemented with strict timers and interrupts to prevent lockups, or the communication has to be handled in a dedicated thread or process that may block periodically yet not be allowed to affect the operation of the rest of the system.

    It’s German engineering and I’m sure the stage will have been built to withstand lots of abuse just like the remote

    Has anyone taken the Kemper-stage apart, or is there any documentation for switches being robust enough to handle stage use and abuse over time? Based on previous experience with older gear such as Digitechs RP1000 I'm a sceptic wrt to rotary knobs and soft buttons on floor units. My old RP1000 has the buttons in a recessed section so they are partly protected if someone steps on the unit, but on the Kemper-stage those buttons completely unprotected. In ways I'm on board with the idea of a floor unit, but I would honestly have kept the user-interface off the unit itself if I were to design one. An app on a USB (or Bluetooth) -attached device would IMHO be a much better approach to implement the controls. One could even supply a low-end tablet with the unit if the desire is strong to provide a "complete" solution. That would leave a much more compact and robust floor unit.

    I believe this is exactly why they decided to re-assign the Type and Browse buttons instead.

    Otherwise, the soft knobs would have to instantly change to editing functions once effect is loaded.

    This may not be possible.

    The 4 buttons above the display are not used much for editing effects. My suggestion would be to make the 4th (right) button "Load Preset", then when pressed switch the rotaries below to "select mode". To further improve on things the KPA could preferably keep track of the last loaded preset for every FX-slot in every rig and set the UI pointing to that preset when the selection-view is opened. For my own use I am more likely to be looking for a different variant of the current effect in the slot than something completely different.

    Remember Widnows 98 and Blue Screens of Death along the way?


    It's not a medical device anyway. Recently even Boeing released a "brand new product" with buggy software (unfortunately for people on both 737MAX flights).

    Microsoft has become the benchmark for a large chunk of the software industry. That is very unfortunate. Powercycling, rebooting or re-installation should NEVER be accepted as solutions for anything. Just consider a simple thing with a dedicated function such as a file-server; A NetWare server with UPS power back in the day would run for years untouched. Granted, those were pre-internet days without frequent security-fixes to apply, but modern Windows-based servers are despite frequent updates also configured for automated reboots at night at least once or twice a week to remain reasonably stable. The only thing MS may be a benchmark for is getting rich on your customers expense.

    The same has been requested before by multiple people, myself included. I have several guitars that are set up wit the Buzz-Feiten tuning system. Reality however, is that I usually play 2-4 different guitars on a gig and another global setting is easily forgotten as I swap instruments. If it was to be usable it would have to be a per-rig-setting, or even better coupled with an ingenious system that would automatically identify each guitar by analysing impedance or similar. It is possible to discover pickup-characteristics by analysing responses to signals across certain frequency-bands. That is complicated to begin with, and different pickup-combinations and pot-adjustments doesn't make it any easier. For now it is much easier to memorise the required offsets and tune to those manually.

    It's a pity that the KPA doesn't have balanced monitor-outputs, but I use the unbalanced monitor-out (1/4" jack) for monitoring (+direct-out for monitoring in stereo). Main-outputs are used for mixing/recording. That way you can adjust your monitoring-volume separate from the signal you send to FOH/recording.

    My vote is for Tom Anderson. I have an older (2004) Hollow T Classic which is great, but I have also tried their new Icon-series Classic-T and it is simply wonderful. The icon-series S and T are closer to the old shapes (thicker body etc), but still has Andersons greatly improved neck-pocket. I'm a sucker for classic sounds, yet don't want to sacrify playability. I will have one heading my way as soon as i find one for a fair price.

    I remember someone from Kemper saying that preset managing would work just like managing profiles.

    It does have to get a lot better than managing profiles and performances in RM. That thing isn't even consistent. For example changing names sometimes works immediately after applying them to the KPA, but sometimes one has to switch to a different rig/performance and back before the display on the KPA/remote gets updated. These days it is more intuitive for all parameter-changes to be applied immediately, preferably backed by an option for rollback, than the current preview-then-save workflow.

    I did place a ticket about this a couple years ago, but have since deleted the email-responses from my archive. Never registered any responses beyond the automated response. The behaviour of the KPA wrt USB-comms hasn't changed noticeably with the last few firmware updates. I mostly run release software, only occasionally testing a beta if there are new features I want to try out. When a computer (Macbook Pro) running RM is connected and it for example goes into hibernation the Kemper may freeze at any time. Sometimes it is enough to pull the USB-cable to get the KPA going again, but a reboot may be required. Currently this isn't critical, as one has to keep the KPA close by for access to its front-panel for many editing operations. It will get a lot worse in studio-settings in the future when many producers will prefer to put the KPA away, maybe in a different room, and control it with the new editor / rig-manager from their audio-workstation or other computer on their desk. Already it is annoying if the attached computer decides to hibernate causing a freeze in the middle of a recording-session. Most of the time fortunately it is only the UI on the KPA that freezes while it keeps producing sound.


    It is not only my KPA that behaves this way, so I believe a hardware failure is out of the question. Recently I brought a stick with a backup to a studio that had their own KPA and got the same problem there. On my own KPA I have tried to reset everything to factory defaults but the unit behaves exactly the same without any changes from the factory setup.


    I have a feeling that the freezes may be a little less frequent than say two years ago, but then I also try to avoid connecting my KPA to a computer unless I really need to so this is just a subjective opinion. The last couple times it has happened to me the UI has had some form of FX-editing open for tuning of parameters. My thoughts were that maybe non-blocking I/O were implemented as an afterthought, but that certain types of messages in certain situations still hasn't been included. These are just guesses based on my own developer experience.


    My opinion as a developer is that any network node needs to be implemented such that its peers are unable to influence its operation. You can not protect against a peer maliciously abusing a protocol using valid messages/instructions. Incomplete messages, faulty messages and failures to respond or complete a message within reasonable time OTOH must be dealt with. The attached computer should be able to throw anything at the KPA, except deliberate malicious messages, with no consequences. A peers failure to respond timely to a message should not cause any problems beyond possibly an error message if that is appropriate for the situation. The KPA should not be affected if RM suddenly stops responding because a screensaver is kicking in on the computer or the computer goes into hibernation with its USB-interface still active.

    Stability has been and is still an issue with a KPA hooked up to a computer. Can anyone shed some light on how this is implemented and why it it so hard to fix the problem?


    I've been involved with networking and related software on all kinds of problems for decades and find it peculiar how the KPA often freezes if there is a problem with an attached computer. Any communications-protocol such a the interface between the KPA and RM should define reasonable response-times for any message og set of messages, and be able to gracefully abort. In my work it has been considered unacceptable for any node to stop working if any one of its peers fail to provide a timely and/or correctly formatted response. If a peer fails it should be flagged as disconnected and required to reconnect properly. Why doesn't the KPA behave this way? Is it based on some OS that is incapable of non-blocking communications over USB?

    Recently when I upgraded from the last beta to the formal release (same) I also wanted to turn off loading of betas in RM after the upgrade. After removing the beta-flag in RM-preferences RM suddenly decided to downgrade to a final release despite just having installed one. I found no other way out than to accept the downgrade which eventually failed because the version RM tried to downgrade to was the one just loaded. To turn off the check-for and loading of beta-releases after loading a final would be quite common to all those who normally only use mainstream releases and only occasionally load a beta to try out a new feature. This can not be how RM is supposed to work. In other words; an attempt by RM to "downgrade" to current must be a bug.