Can we please get some kind of Kemper Editor Software for your computer

    @virango, @OneEng1 and anybody who would contribute to the community editor/librarian - I just thought, before you start working on it, it would be nice to ask community about graphical interface/UI and layout, like ckemper asked about Remote's size and layout.
    I stress this because resembling Profiler's interface 1:1 with many pages for parameters doesn't make sense, since having all parameters on one page is desired state by many I think. 23" LCD screen will allow for that for sure.

    Quote from skoczy

    @virango, @OneEng1 and anybody who would contribute to the community editor/librarian - I just thought, before you start working on it, it would be nice to ask community about graphical interface/UI and layout, like ckemper asked about Remote's size and layout.
    I stress this because resembling Profiler's interface 1:1 with many pages for parameters doesn't make sense, since having all parameters on one page is desired state by many I think. 23" LCD screen will allow for that for sure.

    I always tell my engineers that you first have to establish the "what" you are doing before you start discussing the "how" ;)


    There are power point templates that can be used to create UI stuff with. If a few of you have some ideas of what a good UI might look like, put together some sketches and some work-flows as a starting point.


    I agree that using the UI of the existing Kemper isn't the best approach for a PC program.


    In general, the advantage of a PC program is the huge amount of screen real estate. Using it most effectively is an art.


    Another point that everyone could work on would be to put together a list of uses for the editor. These are typically called "use cases". An example would be "The ability to adjust the PEQ using a graphical interface showing the eq curve".


    Once a good set of use cases can be established, and a general work flow can be agreed on, then we start the process of prioritizing which features get implemented first. Keep in mind that the main architecture has to be designed before the very first feature is implemented. The architecture must be designed to handle all use cases .... even if some of the use cases are never implemented. The architecture should never be the reason a use case is not completed ;)


    Generally speaking the act of sending MIDI commands back and fourth is the easy portion of the program. The difficult part is the work flow and back end architecture IME.

    IMHO, not using the Kemper's interface (to some degree) is counterintuitive. It makes sense to sick with same colored LED's for specific FX and it couldn't be easier to adjust many of the regularly used parameters (like volume, gain, etc.) by hovering a mouse over it and using a scroll-wheel up/down instead of a drop-down or popup window. In sticking with streamline design of the KPA (to some degree) also reinforces the "How to" of the KPA when not using a PC editor, you automatically know where something is at or how to get to it. Limiting what FX can go in which slot in the editor also educates.
    Thanks @virango for all your work!
    This opinion has no expressed or implied knowledge of professional software design. :huh:

    Yep. Keep the layout and color of the Kemper.


    One can still take advantage of all those screen pixels. I.e. the browser knob clicked and there is a huge listbox of all presets. Thats where the editor could extend the Kemper. Best of both worlds.

    Ne travaillez jamais.

    Quote from OneEng1

    Generally speaking the act of sending MIDI commands back and fourth is the easy portion of the program. The difficult part is the work flow and back end architecture IME.

    There's one problem - Kemper doesn't send MIDI data when turning the knobs on Kemper. (it sends MIDI data in debug mode, though. It seems that the data sending feature is coded but not "exposed")


    There isn't a good way to make the editor work bi-directionally :(


    Here's a test made with Ctrl:
    KPAEditor Community Project(vst, standalone, win, mac , linux ) - based on http://ctrlr.org/ .

    Quote from spk77

    There's one problem - Kemper doesn't send MIDI data when turning the knobs on Kemper. (it sends MIDI data in debug mode, though. It seems that the data sending feature is coded but not "exposed")


    There isn't a good way to make the editor work bi-directionally

    That's not quite right. Some of the user interaction is reflected to MIDI, if a client is connected to KPA (sends a special signal), rig change for example. And (almost) all parameter can be requested if needed (e.g when a gui-view is about to be shown).
    IMHO a full featured bi-directionality isn't needed. If you tweak a parameter in an editor, why do you want to do it also on the KPA at the same time? Doesn't make much sense, I think.

    Quote from virango

    If you tweak a parameter in an editor, why do you want to do it also on the KPA at the same time? Doesn't make much sense, I think.

    Unless edits are immediately-reflected, one wouldn't be able to hear their effects; there's only one sound source, and that's the Kemper.


    EDIT: Disregard this post. I took it that he'd asked why we'd want it reflected on the Kemper. Thank you, ColdFrixion!

    Quote from Monkey_Man

    Unless edits are immediately-reflected, one wouldn't be able to hear their effects; there's only one sound source, and that's the Kemper.

    There's only one sound source, I agree. However, he seems to be asking why anyone would have need to twist the physical knobs on the Kemper if they're using an editor for tweaking? It's akin to using the browse knob on the Kemper while running Rig Manager.

    Quote from spk77

    There's one problem - Kemper doesn't send MIDI data when turning the knobs on Kemper. (it sends MIDI data in debug mode, though. It seems that the data sending feature is coded but not "exposed")
    There isn't a good way to make the editor work bi-directionally :(


    Here's a test made with Ctrl:
    KPAEditor Community Project(vst, standalone, win, mac , linux ) - based on http://ctrlr.org/ .

    I was thinking that getting a SYSEX dump up front might be used to get an initial settings read on startup of the program. I haven't looked into the MIDI implementation of the KPA to see if this is supported, or on what granularity it is supported. It would be nice if a SYSEX message existed to get just the current rig. All rigs might take quite some time (especially at 31.25Kbaud).


    Additionally, there must be a way of doing some things bidirectionally. The Uno4Kemper gets some settings (rig, performance mode, stomps activated, volume position, etc) from the KPA on startup.


    Without true bi-directional implementation built into the KPA, there is no way to keep the editor synced with the unit ..... IF someone touches the controls on the physical unit.


    Since MIDI is just a simple UART protocol, a simple serial sniffer is all you need to interpret the bytes going back and fourth. The Uno4Kemper traffic could be sniffed to figure out the basic bi-directional information it is syncing up with.

    Quote from ColdFrixion

    There's only one sound source, I agree. However, he seems to be asking why anyone would have need to twist the physical knobs on the Kemper if they're using an editor for tweaking? It's akin to using the browse knob on the Kemper while running Rig Manager.

    Good pickup, '80s Brother!


    Thanks mate; my bad! Post corrected with kudos to you.

    Quote from OneEng1

    I was thinking that getting a SYSEX dump up front might be used to get an initial settings read on startup of the program. I haven't looked into the MIDI implementation of the KPA to see if this is supported, or on what granularity it is supported.

    Toaster editor does it that way. On startup all parameter for the current view
    are requested. For more information (how to request/change a parameter) you can read the Kemper MIDI documentation (s. the Download section on the Homepage).

    Quote from OneEng1

    It would be nice if a SYSEX message existed to get just the current rig. All rigs might take quite some time (especially at 31.25Kbaud).

    There is. Requesting all rigs is also possible, but it crashes the KPA. It works via USB (s. Rig Manager), unfortunately there is no user space driver available. The protocol is same (as MIDI) + some USB overhead.

    Quote from OneEng1

    Additionally, there must be a way of doing some things bidirectionally. The Uno4Kemper gets some settings (rig, performance mode, stomps activated, volume position, etc) from the KPA on startup.

    There is. The Toaster editor works so.

    Quote from OneEng1

    Without true bi-directional implementation built into the KPA, there is no way to keep the editor synced with the unit ..... IF someone touches the controls on the physical unit.

    As I already wrote in a previous post: I think a true, full bi-directionality is not really necessary, as you can request needed parameter on demand.

    Quote from OneEng1

    Since MIDI is just a simple UART protocol, a simple serial sniffer is all you need to interpret the bytes going back and fourth. The Uno4Kemper traffic could be sniffed to figure out the basic bi-directional information it is syncing up with.

    There is no need for a sniffer. Most of the needed parameters are documented by Kemper (s. above).
    An almost complete MIDI transport layer is already implemented (5.0 functionality is missing) in the Toaster editor and working well.


    If you are skilled in C++ just have a look at the source code.

    Quote from virango

    There is no need for a sniffer. Most of the needed parameters are documented by Kemper (s. above).An almost complete MIDI transport layer is already implemented (5.0 functionality is missing) in the Toaster editor and working well.


    Is support for the new features in FW 5 planned?

    Just been busy with the holiday's work. I'll have a close look at the source soon. Thank you so much for all the effort you have obviously put into this.

    Just stopped by the Kemper booth at NAMM. Couldn't stay very long since I also exhibit for Hosa but I got to meet Matthew, the rep who sold me my amp and shake Christoph's hand.


    Before I left I asked about an editor. Since they are a small outfit and the UI was designed to not need one they hadn't invested in it before, but with all the parameters for the new delays it's hopped to a high priority. They've apparently hired an engineer for it so it's only a matter of time. :thumbup:

    Quote from MementoMori

    Just stopped by the Kemper booth at NAMM. Couldn't stay very long since I also exhibit for Hosa but I got to meet Matthew, the rep who sold me my amp and shake Christoph's hand.


    Before I left I asked about an editor. Since they are a small outfit and the UI was designed to not need one they hadn't invested in it before, but with all the parameters for the new delays it's hopped to a high priority. They've apparently hired an engineer for it so it's only a matter of time. :thumbup:

    Thanks for the heads up @MementoMori! :D