Posts by fourstrk

    I think IF you do this, you have to do this right and go the full way. Bidirectional Ethernet API for the KPA, socket level communication. Some old school C/C++ coding on these uCs, open ethernet API and voilà ... there you have a platform independent COM stack. This would enable DAW plugins as well, by the way.

    How awesome would that be? :love:=O

    Yes, we probably overestimate the skills of our users.

    You might have noticed (as mentioned), that in all KD presets the Tone control is always at noon.

    Thus we should have even more presets called "KlonPushMediumBright" and "KlonPushHardMuffled"

    For me the great thing about the KPA is that I can "browse" through presets which have been created by users way more into the details than I am. To describe my user behavior, I am more "selecting" than I am "dialing in" tones.

    Thus, the more well thought-out factory presets and content I have, the better.

    I remember when we got the new delays. There were lots of presets which have shown various edge-cases and special things that could be done with the delays (which is great!), but I'd really appreciate some more of the "bread and butter sound" presets, especially since the Rig Exchange does not support presets (yet?).

    Why not come up with some "Preset Packs" as you did with the "Rig Packs" in Rig Manager? Maybe a "Preset Pack" for each stomp that you used to let yourself inspire you? You know best how the parameters are implemented, so some more content on this side of things would be great in my humble opinion.

    Anyway, thank you for the new stuff! :thumbup::thumbup::thumbup::)

    Same here. I´m actually looking forward to the Quad Cortex & I think it would fit just great into my enironment - but the reliability of those buttons...i don´t know..

    I can't tell about the reliability of such buttons since I never used nor saw them.

    However, for me, the problem would be that these a difficult to get as a spare part. I never opened my Kemper, but I have seen gut shots. My impression of the Kemper hardware design is, that the PCB has a lot of space and the important user-interface components are wired in a way that they could be "easily" exchanged if needed. Just from the technical perspective, I guess, someone with EE skills would be able to understand the design and exchange most of the things without any "special" tools. Furthermore, a lot of standard components seem to be used, which is a big plus for me. A "normal" latch stomp button is very easy to get, should it fail once. I am not sure about these "special" buttons.

    I know of professionals that travel with a usb stick in their guitar case and rent kemper backlines to do shows. Wouldn't that be the lazy way to go!

    Renting stuff also means cost. Depending on how often you do this, at some point it‘s definitely „cheaper“ to buy things. These people with USB sticks have a Kemper at home and would for sure using a small replacement unit suitable for fly gigs if it was cost efficient, suitable for hand luggage and would fulfill their personal requirements. But - as always - you cannot design it „the right way“ for 100% of the people. :S

    Just for the record:

    You don't even need to have the Remote connected when you update the Profiler. You can keep the Remote unused in a closet for months and skip multiple Profiler updates. Once you connect the Remote, it will automatically be updated.

    TLDR: Yes

    To explain what may be going on under the hood: most probably, the profiler and the remote do kind of a "handshake" and compare their software versions for compatibility. Again, most probably, the firmware flash file itself is stored in the memory of the profiler and is copied over ethernet to the uC of the remote, where it is flashed. After successful flashing the remote reboots, does the handshake again and the profiler recognizes the remote's firmware to be compatible with the one on the profiler. This means that the profiler kind of "carries" the flash file for the remote within itself until a remote is connected which requires to be flashed. As I said: pure speculation and educated guessing. :)

    Most probably, the Remote is driven by microcontrollers which have ethernet capability (obviously), some GPIOs for the switches (obviously), some analogue ones (for the contrast poti and the connectors for expression pedals) and can drive a LCD display (maybe via I2C or similar). Most probably, the brightness is even done in software since the display seems to be the one as in the Profiler, where the contrast is done in software.

    I think one uC handles ethernet RX/TX and some E2E stuff and flashes another uC which is the one driving the unit. Maybe it’s all in one SoC. These are just some educated guesses from the behavior I‘ve seen during updating. I won‘t ever open up the units to find out until I work at Kemper itself, since I am here for guitar playing! 8)8)8)

    In summary, I think it‘s so cool to have such a flexible hardware design that still can be worked with since 2012 and that‘s still competitive. Sometimes, you have to keep it simple to keep it manageable. :thumbup::)

    I didn‘t talk about an adapter. This is too far away from the core business and can be done with standard 3rd party hardware.

    I meant that the app would also work with modelers being connected to an existing network using ethernet cables. Most mixers are connected to switches / WiFi access points and are controlled via ethernet-based protocols. So could the Kemper be, the Kemper Mini could use a built-in WiFi module, whereas older hardware could be connected to a WiFi access point. It does not matter internally as long as there is an ethernet SOCKET. The physical layer, the ethernet INTERFACE uses does not matter for the implementation of the protocol itself. :)

    However, if they do it, I hope they work TCP based, otherwise syncing / handshaking is a pain. Maybe they even build upon a standard communication protocol that can be consumed by other hardware. Why reinvent the wheel ... :saint:

    We are shipping OS 7.5.5 with new units. It makes a difference in our production environment. Beyond that, it is identical to the OS 7.5.4 publicly available.

    Stay tuned for OS 8.0!

    Is that due to changed low-level hardware (end-of-life of some components)? Just asking out of technical interest ... :)

    I would go for WiFi all the time over BT. Why?

    a) The KPA ethernet spec is potentially already existing (see Remote)

    b) WiFi is more stable than Bluetooth and can be easily repeated

    c) The KPA could be included into existing ethernet networks (e.g. at stage, at home, in studios) - since a lot of guys for sure use digital mixers, there is a network existing in most bands anyway

    d) A potential app would be compatible with the classic profilers (not with the stage due to the lack of an ethernet interface - I still do not get why they "optimized" it away ... ethernet is always good to have on a future proof hardware these days which is intended to get several software updates enlarging functionality)

    Just my 2 cents as someone working with product designers. :P8o:D Working on this piece of hardware would be indeed a cool job, I second you. :thumbup::)

    Hmm, with the acoustic simulator and the XLR input which is used for profiling for voice, the KPA could be a crazy good unit for singer / songwriter gigs (and of course other vocalists who play guitar).

    Wow, this would be awesome. :/8|

    Who else would be interested?

    For fail-safe operation, every performance and slots would need a UUID, e.g. hashed from the parameters to point to. If you just point to the performance slot ID, changing the order of the performances or changing performances itself will only be noteable once you have the wrong sound loaded on stage and the drummer is already counting in. Then, there‘s no way to avoid embarassement on stage. :pinch:

    Hence, the „pointer performance“ would have to validate all its pointers on load and give a warning in case of a mismatch.

    A couple of days ago, I think 1-2 days after upgrading to the newest release version, I discovered an issue with my KPA rack + remote. I did not try to recreate the issue (since I was playing live), but luckily this happened only during sound check.

    Here's what I did:

    • Booted the KPA in the Performance mode.
    • Played about 5min in the Performance mode.
    • Switched to Browse mode to show my band mates the awesomeness of the Acoustic Simulator. 8)
    • Browsed to the rig containing the Acoustic Simulator.
    • Played 1 song with the Acoustic Simulator rig.
    • Tried to go back to the Performance mode my moving the chicken-head knob.
    • The KPA did not react.
    • There was no reaction on any input command, neither Remote nor any button on the KPA rack unit itself.
    • However, the signal path still worked, I could play with the rig without any issues.
    • Then, I turned the KPA off with the chicken-head knob.
    • Nothing happened (no shutdown procedure).
    • Switched back to Browse.
    • Switched back to "Off".
    • Then, the KPA turned off.
    • Booted again in Performance Mode.
    • Played without issues in Performance Mode.
    • After some hours, I moved back to the Acoustic rig (it was selected directly from before).
    • Played with the Acoustic Simulator rig.
    • Turned the KPA off with normal behaviour.

    Did someone else discover something similar? :)

    I think that's a cool workaround -

    Since this thread has been moved to the feature requests by DonPetersen I assume that

    (a) there is no smarter way indeed :P and

    (b) the request has been heard over in the Ruhrgebiet.

    So let's see how this evolves and be happy with the overall sound / audio quality of the Acoustic Simulator. :)

    May they fix the cosmetics in a later release. 8o8)

    Have a good day guys!