Posts by heldal

    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.

    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?

    Things would be a lot easier if Factory Rigs and FX presets were organised as "Rig Packs" in Rig Manager with an option to order by date-added/updated. There is a pack for 5.5 factory-rigs, but RM offer no timestamps for these rigs. Dates are not visible for RigPacks like they are for rigs on the exchange. The user is thus unable to determine if a given rig from a rig-pack is old and previously discarded or if it is a new or updated rig worth trying. FX-presets are not yet supported Rig Manager at all.

    To me using the KPA to organise and send MIDI-programming info to devices other than what is tightly integrated (pedals and such) is too much hassle and the functionality too limited. Instead I use a songbook/setlist-manager (Bandhelper) that has any number of MIDI-presets containing program-changes, controls, even raw-midi, for various equipment associated with every song. In my setup I use it to control my KPA, a DMX-application, keyboards and a mixing-console. With this setup I never even need to reorganise performances and slots on my KPA unless I really want to.

    i think inserting the Kemper in a track is the problem, cause you double the roundtrip latency

    Actually, you triple the latency (at least). Normally I would go Guitar->KPA->AudioInterface->Computer(DAW).


    The split introduce no latency and doesn't matter here. Apart from that, before the processed sound from the KPA has been recorded it has travelled Guitar->AudioIF->Computer(DAW)->AudioIF->KPA->AudioIF->Computer(DAW). Using for example a USB audio-interface this will obviously cause a rather "challenging" latency ;-) If you add software monitoring to that the sound travels a 4th time across USB back to the audio-interface before it is presented to the player. Even with the lowest latency audio-interfaces available this becomes a challenge.


    Edit: I didn't read the long message with details before writing the above so I assumed the KPA was used as an insert. With the additional information I suspect that faulty hardware is reason for there to be a 20ms latency on the KPA's main outputs compared to the direct signal when playing through a very basic profile. I would have to add lots of weird effects to make latency that bad. You wouldn't have KPAs in studios all over the world if it had been that bad.

    I would like an option to define an attached toggle-switch to operate the morph-status for the current rig/slot. I.e. an addition to the list with the options to toggle the various FX-slots on or off. I switch between a variety of string-instruments during live performances, including pedal- or lap-steel. My pedal-board with the Kemper-remote and exp-pedals that I use for regular guitars is too big to fit under the steel, and I need to be able to make quick changes not moving a lot of gear around. The solution is thus to use a ABY-switch to select signal-source for input and a separate expression-pedal for volume with the steel. In addition it would be nice to have a separate small toggle-switch that could be used for example to engage a bit extra grit on the sound by morphing to a higher gain setting.

    +1


    There are actually a number of things that could be done to improve boot and shutdown.

    1. Cut output volume.
    2. Implement the networking between KPA and remote so that the connection is established immediately once the KPA is up. As is the remote boots much faster than the main unit and only periodically tries to connect, waiting for fixed intervals in between retries. Had both units, when up, been listening to broadcasts and at the same time broadcasted its own existence those intervals between retries would be eliminated. The KPA once ready could then tell the remote "here I am", then pause for just a fraction of a second waiting for the remote to connect before enabling audio output.
    3. The remote should be able to keep track of expression-pedals being used and made able to sense the resistance/position of connected pedals as soon as it has booted. Currently the position of the expression-pedal is not registered until the pedal start moving. There is a potential issue with multiple volume-pedals being attached at the same time, but in most cases where there only is one volume-exp-pedal used this approach should work just fine.

    With 2 and 3 in place one could boot up the KPA with heel-down on volume-exp completely silent if for example the guitar cable is lying on the floor with no guitar connected.

    I wouldn't reorder performances and slots according to the setlist. For some time I just used a fixed set of profiles with a sensible set of effects prepared for each of my guitars. 1-2 performances. Later I moved to a lyrics/setlist-manager with midi output. Here MIDI-presets (performances/slots) are stored for each song and MIDI-messages sent to the KPA (+ synths, lights, mixer-changes etc) each time a new song is opened. Lists are fast to create and sort, and if the frontman starts picking songs at random I just open a default alphabetically sorted list of all songs. Don't have to think about the Kemper at all despite having a database of nearly 300 songs and almost as many rig/fx combination prepared on the KPA. Once I have entered the necessary MIDI-parametes for each song any band-member can create lists, and I can immediately use the list to control our equipment.

    It’s a bug. The first Rig that’s loaded when you switch on the KPA is loaded from the edit buffer, not the actual stored performance or Rig. Switching forth and back will alleviate the problem. It’s a bug that rears it’s head every now and again when they release a new firmware. It’ll most likely be fixed in the next update, but will reappear again further down the line.

    To me it looks as if it is something happening when the remote is connecting. On bootup everything looks normal, but the moment the remote connects to the KPA a couple effects kick on. Switch to some other slot and back in perf-mode or switch to a different rig and back in browser and things are back to normal. I simply dont trust the KPA to load and initiate the slots in the start-up performance properly so I have made it a habit to switch a little back and forth before I get started. I suspect that there are bits of initialisation-code that still are not executed during boot. The state of rig-filters is another. If you have engaged some filter and reboot with that active you end up with an empty list of rigs in browser-mode. The unit should of course not only load the previously selected filter during boot, but also execute a search with that filter. Instead you have to mess about and re-select/apply the given filter to get back to the state the unit was in before it was shut down.

    The UI isn’t an afterthought, it cannot be.

    That wasn't the impression I wanted to make either. My point is that most developers use (G)UI-frameworks as is and tie ready-made components to their own application-logic and algorithms. Most developers spend a lot more time on making the application do the right things than on how it looks.


    It's not that I think the KPA is all bad. If so I would have ditched it years ago. There are occasions when improvisation is key, and for that I still prefer a traditional amp and pedal-board because that is an order of magnitude faster to dial in, but mostly I'm happy with the KPA. At least it has a front-panel that is much more functional than that of any competitor. Let's just say that there is room for improvement in the UI.


    Note that I focus on the KPA and remote more than the RM. As a mostly live performer it would have to be something very convenient such as a tablet or smartphone-app connected over Bluetooth to make it usable on the road. I use the RM at home for software upgrades and to upload rigs to the KPA, but never take it on the road.

    limiting down the number of controls to be powerful, consistent and intuitive etc, but only he knows, I could be totally wrong.

    This shows how fundamentally different view we have of UI-design. I consider the work of limiting and organising parameters to be passed to an algorithm an integral part of developing the algorithm itself. By your definition things like the linux, BSD or windows kernel with hardware drivers etc would all be user-interface. To me it is only the X11/Motif/gtk/QT-whatever bits that are GUI-components of an OS. Not to say that the development of GUI-frameworks are insignificant, but the vast majority of UI-developers never dig as deep as to extend or modify core (G)UI components. Instead they use most (G)UI-components as is and tie them to their own application logic and algorithms.


    I believe that a considerable part of the KPA has a lot to do with interfacing the hardware and very little to do with user-interaction. There is some generic hardware and some OS/kernel as a base, but a lot of the Kemper is custom hardware that require ditto software. By my definition there is only a few data-driven apps that approach equal effort in front and back-end development, and the reason for that is that the development-tools commonly used for such applications are designed to generate much of the back-end-code used in the projects. Most apps are 90% or more back-end and application-logic.


    Never-mind, what I'm criticising isn't the methods, but the priorities. A simple thing such as categorising effects-presets by effect-type isn't exactly a new idea and I found it shocking that the KPA didn't do that. The front-panel design is excellent, but to me it seems almost as if the development-team ran out of steam once they turned their attention to software (LCD and RM)