Posts by heldal

    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.


    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)

    This is exactly the opposite of reality. UI and workflow takes far longer than anything else in software development. Most algorithms are trivial by comparison because they are definitive, they just work or they don’t, UI meanwhile is a subjective art form where everyone has an opinion and your goal is to make a complex algorithm seem simple and easy to use, which means endless fine tuning and many many subtle details and elaborate interplay’s. Powerful tools are the ones you can use... with ease.

    I beg to differ. You would have to code your GUI in assembly for that statement to be true. I've been a network-engineer/sysadmin/developer since I graduated in the late 80s and my experience is the exact opposite given all the high-level tools and libraries that are available for UI. I have also developed DSP-filtering microcode and that is different world of complexity. While a skilled developer can produce a rather complex UI in a single week, audio-processing algorithms take 1000s of hours of coding and lab-testing, trial and error. The hardware-UI on the Kemper is excellent and I would guess that took a lot of skill, experience and work to come up with, much because trial and error in hardware is much more time-consuming than for software. For the GUI on the LCD (KPA+remote) and the current rig-manager I would be surprised if the development effort has been more than 2-3% of the total number of engineering-hours for the KPA.

    I looked up the Blueamps products. They look interesting, but I'm thinking they may be difficult to come by in the US.

    Every cabinet from Blueamps is built to customer specifications so you're not likely to find them in any stores. In the US you may OTOH find the Mission Gemini II in stores. It is popular among amp-sim users. I would rate that equivalent to Blueamps.

    Normally, you don't jump from Performance 7 Slot 2 to Performance 113 Slot 4, do you?

    That depends on my mode of playing. In "jam-mode" I've got one performance per guitar that cover everything from clean to saturated with a reasonable selection of effects set up. In "per-song-mode", typically when playing in a cover-band, there are individual slots, or maybe two or three neighbouring slots, for each song. Then it is the order of the songs that dictate the jumps. If there are specific slots set up for 100+ songs one often have to jump between slots that are 30-40 performances apart. To re-organise performances and slots in the Kemper each time to match the order of songs on the setlist of the day is both tedious and prone to error.

    Again, I fail to see how displaying the MIDI-parameters on the front-panel of the KPA could make remote-users loose focus. Myself and the few other Kemper-users that I know hardly look at the display on the head or rack-unit during a performance because everything we need to see while playing is displayed on the remote. Am I missing something important? Please educate me! Someone obviously put in some effort to modify the code to remove MIDI-info from the panel when adding support for the remote, but in my mind that seems like a waste of time.

    I've got all the speakers and cabs that make those original amps shine, so I was just thinking wouldn't it make sense to run the KPA through the speakers that made the original amps famous?

    This is true for your sound in front of the amp on stage or at practise, but beware that you may end up with a very different sound from the main outputs that normally is what you record or send to the audio mixer from a Kemper. Some people put microphones in front of the cab, but that does IMHO defeat the purpose of using a profiler. I have played the KPA through an amp and cab at times, but I personally prefer either to go full FRFR with the Kemper or simply use a traditional amp and pedalboard instead. Note that these are my personal preferences. Others may differ.

    We don't display bank nor programs change numbers, while a Remote is connected, because it allows Remote users to focus on the relevant information.

    Honestly, these are tiny numbers within a field that simply is black containing no information whatsoever when the remote is connected. Remote users don't loose anything by having the numbers there all the time, nor does it prevent anyone from focusing on their remotes. I'm a remote user myself, but accessing the digits would have me disconnecting and reconnecting the remote frequently during practise which is both inconvenient and causes unnecessary wear on connectors. The boot+connect-time of the remote makes this approach even more awkward.

    The choice to display MIDI-values in the range 1-128 rather than the actual 0-127 is reasonable.

    There are a few functions that could be added to the network-connection in order to further reduce clutter:

    1. Audio: Use Dante or AVB as transport for audio to/from connectors on the remote (guitar input, FX-send, FX-return, AUX-in etc). Whether an analog FX-loop via the remote is feasible may be questionable even though modern audio over ethernet operates in sub 1ms latency. The analog loop adds extra D->A and A->D conversions which may result in too much latency.
    2. MIDI: Midi In/Out/Through-connectors on the remote. Could be configurable either parallel or separate from the connectors on the main unit.

    Additionally there could be more options added network-wise if the KPA and remote could co-exist with other hosts on a LAN. This would open the possibility for applications on computers, tablets and smartphones (editors, preset/library management etc) to interact directly with the unit(s) with no extra USB or other cables. I'm aware that the remote require PoE, but to add a switching-chip with a second Ethernet interface to the KPA's design shouldn't make it much more expensive.

    Finally I'd like to emphasise that balanced audio-connections and locking connectors should be used wherever possible. For 1/4"-jacks and DIN (midi) there are alternatives, but rarely seen and too uncommon IMHO. Power and network should OTOH be locking in the form of power-twist/locking-IEC and EtherCON. In complex pre-mounted racks with lots of gear you want to make sure that cables don't just pop out in transport or handling. For monitoring there should be balanced outputs (XLR) in addition to the existing 1/4" outputs.