Posts by heldal

    Yep I ll send back the kpa and go full acoustic

    It is not the KPA that is the problem. It works fine with all kinds of acoustic string-instruments too :)


    A magnetic-field strong enough to interfere with the magnetic pickups on a guitar may also be a potential long-term health-hazard for both you and your neighbour so you should really find a solution. I.e make sure the AC is grounded, or fix the AC-unit if it is broken.

    This sounds like magnetic noise/interference (EMI) to me. Humbuckers may work better than single-coils, but I've been to places where it has been impossible to use any electric guitar due to squeal on one or more frequencies in the 1-2kHz range. Most acoustics use piezo to sense vibration or a membrane-based microphone and is thus not affected. A power-conditioner will not help in this situation. EMI-sources require specialised equipment to locate, but turning nearby gear off/on is a start. OP mentions that it seems to come from an AC-unit. That makes sense. Anything with an engine (fans etc) along with electric heaters and other gear that use a lot of power are the most likely culprits. Equipment that are potential EMI-sources should be designed with a grounded shield to keep the noise in so in this case the neighbor with the AC should check to make sure the AC is properly grounded.

    KPA XLR-out is line-level. If your audio-interface expect a mic-level signal you will have clipping. Solutions are:

    • Set KPA main out to -25dB or so. Works for XLR to mic inputs on just about any mixing console or recording interface
    • Use XLR2TRS cables from the KPA main outputs to TRS (balanced) inputs on an audio-interface
    • Use unbalanced TS from the KPA to the audio-interface.

    I've been back and forth between solutions but have landed on a Bluamps Spark. It works for home practise, on stage, and even for gigs that rely heavily on backline-audio with only a small PA for vocals. Yet, when playing gigs focused on a single style of music I still prefer the appropriate tube-amp and pedal-board.

    How do you guys set up your performances?

    This depends on the situation. For me it is usually one of the following two scenarios:


    JAM-SESSION: One performance for each guitar with slots varying from clean to heavily distorted with a sensible set of common effects for each slot. With slots prepared for Tele/Strat/LP/SG, a locked solo-boost in FX-slot X and clear labels on the remote this works fine even for a JAM-session with guitarists who have never used a KPA before.


    SHOW-MODE: Individual slots/performances optimised for each song/guitar controlled by a setlist-manager (Bandhelper). There are songs that require multiple slots, but the majority is done with one slot per song using morph for solo and a couple FX-toggles.

    I have always used .009s for regular e-e tuning on guitars with 25.5" necks and. 010s on 24-3/4". That gives about the same tension when swapping back and forth between different guitars. The exception is for 60's-style instrumental music for which I prefer heavier strings. Rick Beato's test unfortunately ignore both clean sound and sustain. With distortion and/or effects masking the true sound of the guitar you can get almost any result you want with any string gauge given a few minor EQ tweaks.

    Now, the question should be: what is a corrupt rig?

    Yes, and how did it get corrupted ?


    In the case of commercial rigs I assume the deleted rig(s) worked fine at some point. To my knowledge there has not yet been announced any changes that would make old rigs obsolete. Judging by comments and the progress in this thread I don't think this software deserve more than an alpha-tag yet. A beta is supposed to be feature-complete. The ability to preserve old data, and if necessary and possible convert to new formats, should be pretty high on the list of features to complete for any software-release. (Disclaimer: I haven't tried the "beta" myself yet.)

    You wouldn't have anything connected to the USB-port (computer with RM or whatnot)?


    With a computer attached, and especially if the computer is inactive (hibernating), it is just a matter of time before the KPA throws a fit. One of the first symptoms being spontaneous reboots of the remote, then it gets gradually worse until no buttons work and finally after another hour or so the audio goes wonky. Pull the USB and everything returns to normal.

    Probably because it was only intended for communication with the remote, nothing else.

    If that was true then why did they bother to use IP? The KPA has a capable IP-stack and will obtain an address from DHCP and appear as a host on your network if connected. I can't see anything preventing Kemper from implementing many of the same audio-oriented network-functions that gets increasingly common with other advanced audio-gear. The only physical obstacle is that the remote has to be powered from the network, but that can be solved with an external PoE switch. Any modern studio built to a decent standard has both wired and wireless networks and live stages too. It would simplify the setup in many situations if a lot of the I/O could be done via the network. (KPA-RM communications, DANTE or AVB audio etc.)

    Sound-wise I've got pretty much all I need with the current firmware. There is a potential for improvement with new hardware-designs but with the current designs I hope CK and his team focus their efforts on:

    • Bug fixes and general stability.
    • Improved communications with the Kemper Remote. If both units operate as Ethernet broadcast listeners and transmitters instead of relying on periodic connection-retries the initial connection between the devices can be established immediately as soon as the last of the two is ready. The KPA should be able to keep track of remote state across reboots. I would prefer the KPA to mute all outputs on shutdown and keep all outputs muted on boot until the remote is connected and the current position of volume-expression-pedals is known. This could be a global setting for those who like me use the KPA more or less exclusively with the Kemper Remote.
    • Network enhancements (expanded below).

    With an external PoE-capable 3(+)-port switch (or new KPA with 2 ports) there is quite a few opportunities wrt coexistence with other audio-gear on the shared studio or stage-network. For example:

    • KPA<->RM communications over Ethernet/IP instead of USB
    • Multiple simultaneous controllers (PC/Mac, Android devices, IOS-devices)
    • Tablet/Phone touch-screen remote. This can be either device-specific apps or a browser-based interface for example expanding on the KPA-remote test/simulation app that was included in some former betas.
    • DANTE and/or AVB-audio for recording/reamping or even to connect to mixing-consoles supporting such protocols.

    Interesting, should newer kemper OS versions will be incompatible with old profiles?

    No incompatibilities have been announced yet. Not saying it can not or will not, but so far the software designers have not found it necessary to abandon any old profiles/rigs. Crashes are a different story. No profile/rig or any other data fed into the unit should make it crash no matter how badly twisted those data are. Most APIs can be abused and cause unintended behaviour with invalid combinations of parameters (garbage in gives garbage out), but any crash is a bug that needs to be addressed.

    I have the idea of get a tablet (Ipad), with a midi interface, conect it to the Kemper and try to read the midi commands when change presets so I can get the preset name of performance and the names of the profilles assigned in the five buttons of it.

    The irony is that we once had just that in a few betas that were distributed prior to the introduction of the Kemper Remote. The KPA is a computer with networking capabilities and with those betas it was running a simple web-server to which any browser on a phone/tablet/computer could connect and use a webapp with display and switches similar to the Kemper Remote.


    I'm a bit disappointed that Kemper has not since expanded on those networking capabilities. The remote does need to be powered via the network which complicates coexistence with other network gear a little, but an external 2-port switch, maybe itself ethernet-powered from the KPA, could have solved that issue. With networking it would have been possible to eliminate all USB-stuff with its limited cable-lengths etc having RM communicating with the KPA over Ethernet/IP, maybe use Dante or AVB for audio I/O etc. There is a lot of opportunities in networking to improve connectivity and workflow for both studio and live situations. I hope future versions of the KPA will be designed with at least 2 network-ports so that it can communicate with and power the remote while still being connected to the studio or stage network.

    Get some bigger rubber feet from your local hardware-store. If you need longer screws to hold the new feet make sure the new screws have the correct threads and take care to cut them to the appropriate length to make sure the screws do not touch circuit-boards inside the KPA-head. I have one of my KPA-heads attached to a rack-shelf with screws and noticed in the process that parts inside the KPA are visible just inside the holes in the chassis where the feet are secured.

    It is confusing at times when a slot-select-event (remote switch or CC 50-54) following performance-select (bank up/down or CC4) toggle morph. This happens when Perf.Load is in mode "Pending" and the current performance/slot is re-selected, for example by mistakenly switching bank-up/down and back followed by the current active slot on the Kemper-remote. It would be better if a flag was raised once performance-selection has been invoked with remote bank-switches or CC47 to have the first following slot-select-event always set morph off as it would when that particular performance/slot is first selected.


    The current behaviour is causing problems for me in two different scenarios:

    1. When I make a mistake switching manually with the remote ending up back at the current performance/slot
    2. When using a setlist-manager to program the KPA using MIDI CC47 followed by CC50-54 and two consecutive songs are set to use the same perf/slot.

    Pt.2 is solved by using PCs to control the KPA instead of CCs, but that require 625 MIDI-presets to be prepared in order to control all possible perf/slot-combinations as opposed to 125+5 when using CC47 (performance-select) followed by CC50-54 (slot-select). It is of course also possible to implement preset-switching by first select a completely unrelated performance/slot followed by the actual one, but that introduces unnecessary lag.

    One easy option would be to deactivate "Rig Button Morph" in System Settings and this unintended Morphing wouldn't happen anymore.

    Except that I use the rig-buttons for solo tone/boost in a lot of my settings.


    I'll take your suggestion about using PC instead of CCs to choose a slot into consideration. I also use bandhelper. My reason for using the CCs was to minimise mistakes in programming and reduce the number of presets required in the app by selecting performance and slot separately. With my setup i need max 125 presets for performance and 5 for slot. The alternative is to have a separate preset prepared for every one of the 625 possible performance/slot combinatinations.


    That said, even if I change my use of MIDI here I still see a use for being able to set the morph-state as a parameter to the slot-selection CCs. This has been submitted as a feature request (for example 0=off, 1=toggle, 2=on ... to make the previous behaviour unchanged when 1 is submitted as recommended in the MIDI-document)

    It would be practical to be able to handle morph-state for the performance-slot being loaded with CC 50-54. The MIDI documentation for the KPA specify 1 as the only possible parameter to these CCs. There are situations where it would make sense to use the parameter to control morph. Currently when setting perf/slot via MIDI from a song-database-app the current approach even lead to unwanted behaviour when two consecutive songs in the list are set to use the same perf/slot and the second attempt to activate the slot instead activates morph. This is the desired behaviour when stepping an extra time on the remote's slot-select-switches, but not always via MIDI.


    I don't know if it makes sense to be able to use MIDI to set morph in %. Something with a minimum effect on the current behavior may be better:


    One could for example implement the following attribute-values for CC 50-54


    • 0: morph off
    • 1: morph toggle (if current slot is selected again)
    • 2: morph on

    I would really like to have a global parameter (system setting) to set the default time morph takes to engage/disengage using the rig/slot selection-switches on the remote. For me the 2 seconds transition is too slow and I have to edit a lot of rigs to make it faster. A default of about 0.5 seconds would make more sense for my use. Implementing such a default would of course affect all existing rigs. For that my suggestion is to apply changes to the default lag to all existing rigs that used the previous default and leave the rest untouched.

    Would be cool to have the Morph be Momentary in some cases (rig based).

    As already mentioned above you can have momentary morph on the rig/slot-selection-switches on the remote. By default morph with these switches takes 2 seconds, but the morph-time can be set per rig. The only thing I've been missing is an option to set a global default morph-lag to somewhere between 0.5 and 1 sec instead of the default 2 sec. I often use morph for solo-boost and have to edit many rigs to make it faster. With the default adjusted to 0.5 sec I would almost never have to adjust it.