Posts by fourstrk

    Hi,


    - Mic up your amp the way you would play it live in another room and send the sound to your PA

    - Dial in the sound until you are happy with what your hear

    - Add the KPA to the signal path, it should not change anything in the perceived sound

    - Profile your amp and A/B with the real amp during the profiling process

    - Once you‘re happy with the result you should be able to get the same sound out of the KPA that you got with your amp

    - If you still do not like the sound then it is not about the KPA

    - If you do, you can profile various settings of your amp

    - Then, go check other rigs on the Rig Exchange


    This is the way I did it and maybe an easier starting point than digging through the overwhelming amount of available rigs.


    Don‘t blame the messenger (in this case: KPA)! :)

    No matter which manufacturer, it‘s possible to get good sounds with all of them. But for me, it is about the feeling when playing guitar and the response of the unit to that. Despite it is very subjective you will never find out via YouTube. You have to play the units yourself.

    You can still reamp. You only need an output from the DAW to the Kemper input and another output from the Kemper to the DAW (audio interface).


    Many people use SPDIF since there‘s less DAAD conversions involved (preamps etc.) and - personal opinion - it is easy to use.


    However, SPDIF is no requirement for the reamping concept.

    If they using a database in the background (as they seem to do on the KPA itself) there is no limit (except HDD space) but searching for rigs and loading RM slows down the more rigs there are in the DB since the computer’s RAM is affected.

    I agree. It is all about the implementation.


    I would argue that anyone that OOP is a bad tool for use in embedded systems. C++ OOP consumes many times as much ROM space and RAM space as straight C does. While it can execute just as fast, it usually doesn't simply because of the moving of a butt ton of memory object information around.


    It is amazing what the KPA accomplishes with its minimal processing and RAM.

    The advantage can also be a disadvantage, depends on the perspective. Writing efficient C code which scales and has no memory issues is way more difficult than in C++. You really have to know what you are doing. C++ makes a lot of things easier and you can incorporate C code into a C++ project. So from my perspective, it is not an "either / or" but complements each other. One has to find to find the sweet spot where to draw the line. Typically, there's a C interface with a C++ wrapper. So you can call the functions implemented close to the hardware with a high-level interface. I would assume that Kemper did it similar or even like this. :)

    In my experience of the recent days of testing I would say the internal boost, overdrive or distortion stomp effects CAN boost the amp. But in a relatively narrow range compared to external analog pedals. Some analog pedals can have such an insane amount of boost that they will likely clip the input stage of the Profiler. If you try to compensate (and thus lower the level going into the Profiler) you can't achieve what the pedal does to a real amp.


    Even if an analog pedal boosts the Profiler's input into some clipping, the overall "extreme boost" still reaches the amp block. The internal boosts don't do that, there's a very obvious (audible) limit where an increase in the volume parameter starts to "compress" in a strange audible way. It might not be visible in peak levels but in certain situations (where it gets very obvious) you can see it happen on a short term loudness meter.

    Well summarized, thank you! :thumbup:

    So, lightbox, I am not sure I understood correctly:


    To conclude, the issue is that due to dB limitations within the internal sound processing chain, when adding the the KD / OD, the output signal is subject to a volume drop and this only happens if the main signal volume is above a certain threshold at the beginning of the chain (before the amp)?


    Analogue "extra" pedals in front of the KPA have a different effect on the sound which cannot be achieved with the internal effects since they raise the "voltage" that is coming into the input of the KPA compared to the internal effects "just" shaping the sound?


    Can you confirm or correct me, if I am wrong somewhere?


    I think all other "issues" that have been discussed here, e.g. the behavior of the parameters of KD / OD, are more a feature than an issue since they have been implemented consciously that way.


    By the way, for me having just background about physics and not so much about audio engineering especially, it is awesome to read this thread and see, how you all are into the subject and give direct feedback to enhance KPA OS 8.0 for all of us. Thank you lightbox  Atlantic  Wheresthedug and all the others who are investigating this!

    Hmmm... I wonder if they'll come out with, or support a USB Wifi module for older units?

    I don‘t think so since this is not their core business. The maximum that I could imagine is that they „support“ certain hardware.


    For me, it‘s more probable that you have to attach the KPA to a WiFi access point or router. This way, they do not have to mess with additional hardware.

    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. :)