Posts by heldal

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.

I thought this issue was with non-responsive USB-hosts in general. Apple use generic USB-controllers AFIK so PC's with the same USB-controller/circuits should be affected too. Are there really no PC-users who have the same problem? Unfortunately I don't have a windows PC to test with (only MacOS and linux here).

Quote from Wheresthedug

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.

Quote from Raoul23

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.

Quote from Slyman

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.

Quote from skoczy

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.

MIDI in combination with the remote works fine. Not only that, but to me it is key to be able to switch quickly between performances/slots that are far apart without stepping like crazy on the performance (bank) up/down switches.

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.

ticket was filed just prior to my last message with the same content.

Quote from TomR

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.

Maybe this could be formulated as a feature request if more people find something similar useful?

Is there a way to define defaults for morph?

By default morph does nothing. I was thinking along the line of for example making it a default volume-boost instead (by a predefined delta-Db), unless something else is manually configured. After a period of using a locked boost in slot X as a global solo boost I've moved on to use morph instead because there is a need for more flexibility. There are songs for which +1dB is enough, while others need +10dB. A default of +some_constant dB is often OK though. Thus a "default if nothing specific is set" would be be a time-saver.

The profiling is essentially a bit of software and a couple extra inputs and outputs on the unit. To play/process profiles requires just about the same hardware as the profiling itself so I don't think a profile-player would be much cheaper than the full version. Would you expect a computer to get much cheaper by dropping its mic-input?