Posts by heldal

    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.

    I have not had the problem with remote not working, but the boot sequence seem to have changed. In the past my profiler (unpowered head) would fire up POE to the remote early during boot resulting in the remote completing its boot-sequence first and sit waiting for the KPA to get ready. Now there is no power provided to the remote until the main unit is up and running.


    Maybe this is an attempt to speed things up as it always have taken 20-30 seconds for the remote to get attached once both units are ready probably due to periodic retries to reconnect, but it isn't the best approach. The most efficient method is to implement a broadcast-listener on both units and have them both broadcast its presence once they are ready. Then the unit that is ready first will immediately be notified when its peer is available and thus able to initiate immediate connection. It should only be a matter of milliseconds before the connection is established once both units are up and running, not 10s of seconds.

    Is it not BETA anymore?

    Apparently not. Both RM 2.3.13 and OS 7.0.9 are now formal releases according to the information on the download-page. Nothing yet from Kemper in the Announcements sub-forum though. Don't know if that means anything, but I would normally expect announcements for such a major update to be prepared well in advance of the actual release.


    Edit: the announcement for 7.0.9-final just appeared in the forum.

    Also interesting that the stage’s own OS is larger nearly double?

    That would for example be the case if you compile the same code for 32 and 64-bit instruction-sets. We know there are other differences in hardware (S/PDIF) so maybe the CPU has been upgraded too? (pure speculation on my part)

    I share other's concerns about an editor that relies on a usb connection.

    USB doesn't have to cause such problems. I've got other types of gear which functionality never has been impeded by anything connected to its USB-port. What I fear is that the problem is at driver-level which puts a fix out of reach of CK and his team. I believe the KPA is based on some minimalist, preferably real-time, operating-system which would be responsible for handling networking/USB I/O. A network-scan I did some time ago by hooking the network-port to my LAN was unable to clearly identify the system, but the exposed part of the network protocol-stack was pointing to some form of Windows. You'd need internal knowledge of the design to be certain.


    That said, I think we should drop the bug-discussion from this thread. My point was only to emphasise that I wish CK and his team are able to solve this issue with a firmware-update accompanying the editor when it finally arrive. A failure to do so makes the KPA/editor combo a lot less desirable for uses where the editor will be left idle, but remain connected, for longer periods of time.