Posts by heldal

    While I appreciate the approach with the Kabinet and Kone these will still be unable to defeat bad/unusual acoustic properties on location. When placed in a corner on a cramped stage any amp/speaker-combination will sound way off from what the same gear sound like under ideal conditions. I believe this problem largely could be defeated by analysing the room through a microphone placed near the position of the guitar-players ears and from the analysis apply filters to an enhanced monitor-output-EQ (multiband) on the KPA. When used with monitors other than the Kabinet or Kone this solution would also compensate for the characteristics of the actual monitor/speaker(s) used. The key to this solution is to have analysis-software specifically tailored for the microphone used. There could be models for a set of specific 3rd-party microphones, but the most realistic solution may be to deliver the solution in the form of an optional measurement microphone and corresponding KPA software-update. Finally, it should be possible to adjust the enhanced monitor-output-eq to taste after the automatic room-compensation has been executed and applied.


    I know there is more to a rooms acoustic properties than what can be adjusted with EQ, but EQ goes a long way for the short-range between player and speaker on a stage or in a rehearsal-room. I invested in a high-end stereo monitoring-solution for my KPA some time ago. It works very well under decent conditions at home and at rehearsal, but due to "boxy" sound on many stages I have since complemented it with a stereo multiband EQ sitting between the KPA and monitor. The approach outlined above would both eliminate the need for additional equipment and significantly reduce the time spent adjusting the EQ. For gigs covering many different genres the manual process include playing, listening and adjusting (at gig volume) for at least 4 or 5 different rigs/profiles on the KPA. The adjustments made to a flat EQ for a clean tone may need further refinement for distorted sounds and vice versa, but I am always able to find a setting that works reasonably well for the entire gig.

    I have observed the same as reported above.


    Conclusion: firmware 7.2.1 changed the assigned function for the tap-button on the remote. Later releases can not know whether the change was intentional or accidental so everyone who have loaded 7.2.1 need to check button-assignments for the remote in system settings.

    Hardware: Non-powered head from 2015

    OS: 7.2.2.16146

    Rigs: 808

    Boot-time: 1:08

    Time till remote-ready: 1:19 (9 sec after the main unit)


    I don't know how much integrity-checking is done at startup, but it it either a lot or the unit must have very slow NVRAM.


    The extra time waiting for the remote is frankly unnecessary. The current implementation reies fully on periodic retries to connect. Recent firmware delay power-on to the remote in an attempt to align the boot processes for each unit, but it is hit or miss whether they both are ready at the exact same time. The better approach would be to make both units work as broadcast transmitters and receivers and make the first unit that get a swift response (<100ms) to a "hi anybody there" message responsible for establishing the connection. That would eliminate any unnecessary waiting for the other unit to become active.

    Can someone rename this thread "Kone logistics" and start a new Q&A-thread instead. I don't mind threads discussing just about anything, but please have some respect for the topic! A good Q&A-thread should have an initial post that gets maintained with new Q&A-pairs added as new important/common questions appear.

    Works great but it requires 4U of space.

    If there is a bit of room at the bottom and the rack will let you mount the KPA straight to the bottom you may squeeze it into 4U, but on a shelf it needs 5U. I've got my toaster in a shallow SKB 6U rack with a Line6 G90 1U wireless-receiver on top and a Furman power-conditioner mounted vertically next to the KPA.

    Is it just my perception or with the new OS the Unit boots up faster?

    I can's see much difference. My KPA takes uses 1min3sec to boot to tuner. Then add another 14sec before the remote gets connected.


    To me it looks like the NVRAM use to store the firmware must be very slow, but there isn't much to do about that.


    The delay to have the remote connected OTOH is simply unnecessary. Recent versions of firmware delay power to the network port to prevent the remote from booting up before the main unit is ready and sit waiting with periodic retries to connect. The better approach would be to implement both the KPA and the remote as broadcast transmitters and receivers. Then each unit would first ask if the other is present before connecting, and fall back to wait for the other if there is no response within 50-100ms. With no delay on power to the network one would thus have instant connection once both units are ready, with periodic retries only as a fallback in case of wiring problems etc.

    After upgrade the KPA suddenly had rigs sorted by author in Browser. An attempt to change back to sort by name produced a crash. Ticket filed. After another reboot the unit seems to be fine.

    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.