Posts by heldal

    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.

    of course, because we don't even know about such an issue.

    I filed a ticket way back when I first encountered the problem which there never was much feedback for. I've had my KPA since before the first RM was released so I guess that ticket should date sometime within the first month after RM was introduced. Then again more recently (ticket #KA00168926). I even received tweaked firmware for testing last June, but it unfortunately behaved just like before. I sent a description on how I reliably can reproduce the issue within an hour or two, since then I have only used RM briefly to pull a few rigs from the exchange. I submitted another question to the forum to check whether others with different types of computers have the same problems as I do with my Macbook and got confirmations from windows users too. On June 20th I got a follow-up mail with request for further logs which were promptly submitted, but nothing since. I do occasionally test some beta software, but only when I do have the time. Music is a hobby, and I prioritise practise and gigging. I make my living as a software/network engineer, but have no wish to run a software lab in my spare time. I do follow up when I get direct questions about KPA stuff, but mostly I just want to turn it on, play and switch off.


    Don't get me wrong. I love my KPA, and even RM when it is used interactively to organise stuff and pull info from the exchange. It is only in a setting where RM may be sitting more or less idle for longer periods of time that the problem occur (recording/rehearsal). Still, it should not be necessary to always have to take care to disconnect the USB-cable from the KPA as soon as you're done with whatever you had to do in RM. It is so annoying during recording or rehearsal when the remote becomes unresponsive and goes into its boot-loop while the KPA gets stuck while playing. Granted, the unit normally keeps on making sound for the rest of the song, but all internal (knobs/buttons) and external controls (switches/exp-pedals) are non-functional until RM is disconnected or the KPA rebooted.


    My worry for the editor is that it will be based on the same USB-communications as RM that I'm quite certain is the source of the problem. The KPA can not protect itself from connected gear/software that deliberately abuse functions offered by the KPA, but a malfunction/anomaly in any piece of gear attached to the KPA should not be allowed to affect its function, performance or reliability. If this problem boils down to an unresponsive USB-peer it is still a failure on the KPAs part. Any attempt to send or receive information on the USB-interface must be required to complete within a defined number of milliseconds. If not, then the operation must be aborted.

    I'd much rather have CK and his team make the software, both KPA firmware and RM/editor, rock solid than getting an early bug-ridden release. RM has always been, and still is, a total PITA. One simply can not leave a computer hooked up to the unit for any longer period of time, which for many studio/recording guys is totally unacceptable. One has to be able to keep the KPA available as an audio-resource on a shelf like any other audio-processing-unit without wondering if or when it is going to lock up. It is not the first piece of gear I've had with problems, but the first where something as serious as system lockup doesn't seem to be taken seriously by its developers. It's been going on for years across countless firmware-releases. If it is as hardware issue that makes it un-fixable, be honest about it and inform the customers. I just pray this gets fixed with the new software, but I'm not holding my breath.