Posts by heldal

    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.

    I'm using a setlist-manager app to control various devices including the KPA. The settings in perf-mode for each song is chosen with CC47+[perf-1] to choose a performance followed by CC50-54 to select the slot. This works fine except when two songs in a row are set to use the same perf/slot. At that point the KPA handles the input as a double-step on a slot-button on the remote and activates morph. I often use morph to activate my solo vs rhythm settings so this is not ideal. When morph is activated this way it also seems to mess up the morph timer. When stepping on the remote to deactivate morph that has been unintentionally activated via MIDI it drops immediately back to its starting position (possibly a bug).


    The MIDI-manual for the KPA specifies 1 as the only possible value associated with CC's 50-54. Maybe this could/should be extended to control how morph behave when selecting a slot? For example: 0=Inactive, 1=Toggle, 2=Active (1 for toggle means that the current behaviour is unchanged for anyone relying on how it works now)


    I know it is possible to send a sequence of CCs to first select some irrelevant perf/slot before going for the correct one, but that is extra info that has to be maintained in the song/setlist database and loading+activating two different slots on the KPA takes a little extra time.


    ... or is there some other way to avoid having the current perf/slot being re-selected via MIDI mess with morph?

    i use M Britt some M13 profiles. It sounds great with my fender tele when live with a band. But i need to find another profile for musicman and LP. Yes musicman closer to fender strat but i think they are still sounds different. I'm thinking to buy real fender strat. I never do an exchange yet, but maybe i will.

    If your Cutlass is the cheaper Indonesian-made Sterling I may agree. The high-end Cutlass OTOH is tonally almost identical to a contemporary US-made Strat, and ergonomically a slight improvement over the Fender IMHO. I would only swap that for a real vintage strat or a customshop reissue, if even that.


    You say nothing about what genre you are aiming for, but I'd be surprised if you can't find decent profiles for almost any type guitar on the rig-exchange if you search for common amp-types such as tweed, blackface, vox, plexi etc.

    that's correct! Same here...

    If I put in on "all rigs" and back to "favorites, only the "favorites" are shown... like after the update "all rigs" is active while " favorites" is displayed...

    Little bug...

    Isn't this the same problem the profiler always have had? I.e.that the units preserve previously selected filters when booting, but fail to apply them until the filter is de-selected and re-selected.

    looks like the XLR connector on the interface is mic level.

    have you tried a simple 6,3mm cable instead?

    Could also drop the main-output-level on the KPA to -25dB or so.


    It should be easy to spot if output gain is the issue. There should be peak/clip-indicators going off on the audio-interface and/or in the DAW if the level is too high.


    In my experience you can make any interface work by either matching levels by choosing the right ports, or by turning down the KPAs output for the case where the KPA is going into a mic-level port on a mixing-console or audio-interface. I find myself mostly hooking up to mic-level inputs so the main output of my KPA is more or less fixed at -25dB.

    I love my KPA, but the JTV59 not so much. I finally gave up on the JTV after having had one for about a year. The guitar played and sounded good, but couldn't cope with normal use. The proprietary rotary-switch would only last a few weeks. Repairs took forever (up to 3-4 months) due to proprietary parts that seemed to have to be made to order and shipped by boat from Asia for each repair. My JTV spent a lot more time in the workshop waiting for parts than I could actually play it. The idea is brilliant, but the execution miserable. That's my experience. YMMV.

    Kemper doesn't actually provide a release-note as such, but rather a changelog which to me look like a redacted version of developer comments from their source version-control-system. It basically serves the same purpose and doesn't change my initial request. I would still like to have known bugs/problems available and maintained for a period after release.

    Just have a look at the various pages of output settings. On page 2 you find the options to set the output levels for the outputs that are not linked to the master.


    I use an even lower level for main out (-25dB) than what has been recommended above. Had a couple sound-engineers asking me to lower my volume when I had it at -20dB, but have had no complaint so far with -25. I wish the main outputs had a physical line/mic-level toggle-witch. That would eliminate quite a bit of confusion.

    Keep watching the video. At some point of the interview he acknowledged that a guitar speaker experience is still a challenge for digital amps, specially for players not used to mic’ed amps sounds. In fact, he said that IEMs have the same issue with analog amps for some players that miss their guitar cabs. Hence, his approach to mitigate that is the Power Amp option and his new Kones speakers, to be released some day.

    I heard that bit. There's a lot about what the player is hearing and how, but I'm still missing CK acknowledging the value of the interaction between speaker and instrument. As if everyone would have all their needs covered if their IEMs could sound just like an amp.

    Can you tell me more about it? Which techniques do you mean? I only know about feedback as interaction, which i can get pretty easy with the control room speakers.

    Exactly, you need speakers powerful enough to provide feedback. CK keeps going in the interview as if in-ears or anything you can hear is adequate. Feedback doesn't seem to be included in his agenda at all.

    Lee Anderton misses an important point in the conversation. CK keeps repeating that speakers are not really needed which clearly isn't correct and he should have been pushed on that point. There are a number of techniques guitarists use that depend on some form of interaction between the instrument and a speaker.

    This isn't a request for functionality, but for a minor improvement to the communication between manufacturer and users.


    Whenever new software is released it is accompanied by a release note in which a description of new features and bugs fixed is and should be given the most attention. I do however miss a section about new bugs that should be added and maintained at least for a period after the release. I know that a lot of users don't bother to examine release-notes before installing upgrades, but many, myself included, do. I have more than once wasted precious time on upgrades that later had to be rolled back due to bugs I would have discovered if I had the time to study the forums carefully in advance. The information about known and confirmed new bugs should be available in RM and on the download-page, as well as on the forum.


    An example is the issue with the upgrade to 7.x deleting all snapshots that has been an unpleasant surprise to some users. This should, as soon as the issue was discovered, have been made public and clearly visible to users trying to perform an upgrade.