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

  • Yes. Exactly.
    It would be hard enough to introduce a full fledged editor created internally by Kemper. The work flow can be controlled, and only the series of commands that the editor actually makes need to be validated.


    Creating a 3rd party API (application programming interface) opens Kemper up to a nearly infinite number of work flows and command sequences that would result in many many many failure paths.

    I'll say this: the API "endpoints" (for lack of a better word) they've had in place since way back in FW3 seem to be VERY comprehensive. You're essentially doing call/response style NPRN integer & null-terminated string messages wrapped up in SysEx. It's cumbersome but well organized. In fact, I can't think of many parameters that aren't addressable. Of course, file operations (saving, deleting, etc.) aren't supported, but I don't think that's mission critical to a viable editor.


    My point is... a comprehensive API already exists (essentially) and it's simplicity, extensibility, and minimal entry points makes it easy for Kemper to maintain its walled garden.


    A editor is still a TON of work, but 98% of the tools are already in place.

  • I'll say this: the API "endpoints" (for lack of a better word) they've had in place since way back in FW3 seem to be VERY comprehensive. You're essentially doing call/response style NPRN integer & null-terminated string messages wrapped up in SysEx. It's cumbersome but well organized. In fact, I can't think of many parameters that aren't addressable. Of course, file operations (saving, deleting, etc.) aren't supported, but I don't think that's mission critical to a viable editor.
    My point is... a comprehensive API already exists (essentially) and it's simplicity, extensibility, and minimal entry points makes it easy for Kemper to maintain its walled garden.


    A editor is still a TON of work, but 98% of the tools are already in place.

    Hi benvigil,


    I took a quick look at the MIDI implementation. The only thing I really wanted to do was to move performances around, name them, and gather the names from the unit for display on the app. I wasn't able to find any way to do this, and the folks at Kemper informed me that extending the MIDI implementation to be able to do this was not planned.


    Where are the NPRN's documented?

  • As a development manager, I see it as an excuse for not having specs solidified. Without a proper foundation, anything you continue to build will not be built on a solid foundation. Some managers hear a buzzword, and think it's the greatest thing, only to find that it doesn't help their project's bottom line.

    This is what I mean when I talk about agile often being done wrong and misapplied. The foundation you mentioned is a definite outcome of agile.


    Not trying to offend, but having a development manager that doesn't believe in the benefits of agile is a huge red flag to me.

  • This is what I mean when I talk about agile often being done wrong and misapplied. The foundation you mentioned is a definite outcome of agile.
    Not trying to offend, but having a development manager that doesn't believe in the benefits of agile is a huge red flag to me.


    That's fine. I've been in the computer world for any decades. I've seen paradigms come and go. This is one that I see as a huge waste of time.

  • Time to close the thread? It has deteriorated it some super dull middle software management discussion.


    Have some Lisa-X and her bro, these two rock.


    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    Editor will eventually come or will not.

  • This thread is about computer software, not child prodigies. Dull to some is interesting to others. I didn't make it to the end of the video.

    Here is some more, this time with Kemper! (no editor included)


    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

  • That's fine. I've been in the computer world for any decades. I've seen paradigms come and go. This is one that I see as a huge waste of time.

    Me as well.


    This one has a history of missing delivery dates, and producing products that don't adhere to customer requirements.


    Its been my experience that developers love it, and most managers dislike the results and lower productivity.


    On the original topic ......


    Does anyone know if there is a list of non-registered parameters for the Kemper?

  • No, I want to read it, as I am mildly interested though. Not about this middle management issues and fears though, don't care about it.

    Just because you don't care doesn't mean others don't, or the insight isn't valuable. It's also related to the topic at hand about hardware & software development.

  • My humble guess is that there are some significant changes on the horizon for the KPA. Rather than have to re-work an editor (and the inherent issues of a first release) to accommodate a software release that has foundational changes, they've decided to wait until the software/firmware has stabilized with the new features and then release the editor.


    As it is, they have to track changes in the Kemper and the Rig Manager. Adding a third "moving target" (the editor) would only increase support overhead and customer dissatisfaction.


    Let's say, for argument's sake, that they announce a floorboard version (i.e. Helix). Any editor would have to support both hardware platforms. And, if they announce that, it would likely have a different processor, AD/DA, etc. to keep the chips from being obsoleted by the supplier into the future.


    From conversations at NAMM 2016, I think many will be stunned at some of the things in the pipeline (the fertile mind of CK). I won't say more than that - not trying to be clever or exclusive, just wanting to be respectful of things said in confidence (and which may have changed drastically in the last 2-years).

  • From conversations at NAMM 2016, I think many will be stunned at some of the things in the pipeline (the fertile mind of CK). I won't say more than that - not trying to be clever or exclusive, just wanting to be respectful of things said in confidence (and which may have changed drastically in the last 2-years).

    Given the delay in delivering the new reverbs, I'm not holding my breathe.


    I'm certain CK is constantly in inventor mode and has all kinds of ideas. I'm also certain most of those ideas never make it past the napkin stage. :)

  • Keep cool everybody ... this DevOps discussion in more or less interesting (having to deal with this on daily basis) but the Agile topic is wrong in this thread.


    My personal opinions:
    - Editor has to be Ethernet/TCP based with USB wrapper
    - Therefore it can be used more flexible than over USB
    - USB helps for direct connections
    - Apps are possible in future this way


    - MIDI is cool for commands but not transferring data


    - RigManager and Editor have to be streamlined into one product. Otherwise there is too much overhead and it does not make sense to split up Rig Managing and Editing into two seperated application (not user friendly).


    Creating a community based MIDI editor out of desperation is a waste of time in my opinion. I would not do this in my spare time since the requirements I set to this kind of software can not be fulfilled without the component owner's help (API).


    If I did it, I would do it like this. jm2c ...

  • The tech for transferring rigs (preview) from rig manager is already up and running.


    No need for a stand alone-editor to edit presets on the Kemper itself. Just hope they make it (or if) edit the .kipr-files in rig manager on your computer, auto-quicksave and send it as preview after every change you make.


  • Let's say, for argument's sake, that they announce a floorboard version (i.e. Helix). Any editor would have to support both hardware platforms. And, if they announce that, it would likely have a different processor, AD/DA, etc. to keep the chips from being obsoleted by the supplier into the future.

    If it's a floor version that's of the same generation as the Kemper head/rack, then there's no need additional work to make an editor work with it. Consider, if I had the ability to machine metal, i could build a metal case and cram all the internal hardware, LCD screen, knobs switches and jacks from KPA and a KPA remote inside. I could even connect them the same way with an internal cat 6 cable if I wanted to! From a software standpoint, it would be identical to a head or rack + the remote. It's the reason I can't understand after rolling out the remote 3 years ago, they didn't role out an all-in-one floor product a few months later. Literally all they had to do is design a metal case that holds the contents of the two pieces of equipment that they already developed. No new programing or glitches, just figure out where they want to mount everything.


    I think if we don't see an editor within the next 6 months we will never see one. At some point, they will want to role out a second generation of Kempers. If thats on the horizon at this point, why would they want to role out an editor on the old product? Consider that after every years new Apple OS version, you have to wait 6 months before your recording software isn't glitchy to upgrade. It takes companies whose primary product is a piece of software and it takes them a long time to make their software function correctly. How much more so for a small company whose main product isn't software? It means continuing to maintain and provide support for an editor for many years, all the while trying to peddle a new product.