Posts by heldal

    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.

    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.