Document the Ethernet communication protocol

  • I know ... this is a question which can be discussed through and through with all its advantages and disadvantages (especially internally at Kemper) and there will maybe be two opinions that divide people ... but let me explain:


    Knowing that the Remote can control the Profiler (or a subset of controls at least) via Ethernet, why not document this interface? For reliable live use it's no security risk, since you are wired up directly to the KPA in most cases. And all people who would go another way would know what they do (Router, Switch etc.). Knowing the editor, maybe you already use sockets to communicate over USB? May be smart since you could share the communication stack between Remote / KPA and Rig Manager / KPA.


    Having (at least a subset) of Ethernet protocol messages, plug-ins for DAWs, remote control, multiple KPAs, switching etc. could be done remotely. I'm sure that some people would come up with quite cool projects, e.g. switching lights over Art-Net when getting a callback message from the Kemper ... How cool would that be? 8)


    You could throw away the MIDI layer of complexity (although knowing that sometimes "old-school-stuff just works" 8o).

  • 1) Document the Ethernet communication protocol -YES

    2)You could throw away the MIDI layer of complexity -NO


    I belive Remote has a fixed logic - it sends only what was pushed and whole bonanza is in the KPA itself.

    MIDI allows you to decide what to switch with the controller button. You can achive more advenced and custom switching with MIDI.


    I would preffer MIDI implementation over ethernet like RTP MIDI.

  • 2) Compared to now, you could directly send via Ethernet without MIDI and additional HW.

    I agree - what I'm talking about is MIDI via ethernet like RTP MIDI so you don't need additional hardware .

    What are the benefits? You can use MIDI in almost every DAW withouth the need of special plugin. Or you can write your own plugin to automate MIDI . I bet even the RM could work with such connection instead of USB.

    I think with remote protocol you could only emulate remote behavoiur. Sure you can emulate similiar results with the morphing. But you can't send the patch to FX module A for example saved with your DAW session(with use of the CTRLR plugin for example). Whole KPA concept (rigs , presets files )are based on MIDI .

  • Even if this was a good idea - and I'm not saying it isn't - I don't see how it would ever end up on the product roadmap.


    Let's explore why:


    Staffing:

    Kemper would be a small team of engineers. I'm guessing under a dozen. Probably less than half of that.

    Prioritization of work in a development shop - especially one as specialized as this one - is of utmost importance.

    Onboarding new staff is expensive - even more so when the engineer doesn't work out.

    So the development overhead for a device like this is high. Cleaning up the code and documenting the spec would be an expensive task to undertake.



    Competition:

    As a developer, if I had the ethernet spec for the remote (I'm too lazy to sniff it), I'd be building my own remote. Probably with more features (Blackjack an Hookers). As an entrepreneur, I'd want to sell it. Why would Kemper want to introduce competition where there is none?


    Test coherence:


    Whenever a Kemper's developers merge to their repo, it's probable that a suite of unit tests fires to ensure all of the functionality that's present works as expected. It's much easier to do this if you control communication end - to - end. As soon as you introduce a third party component - such as an ethernet plugin or third party device - this becomes significantly more difficult. I'd hate to have to write the unit tests for this.


    Product Roadmap:


    What would we rather have the engineers work on - documenting (and subsequently enhancing) a feature 0.1% of the user base would take advantage of... or work on new effects and editing functionality that 90% of the user base would use?


    I have no inside knowledge, just well versed in the realities of a continuous development cycle.


    KPA Unpowered Rack, Kemper Remote, Headrush FRFR108s, BC Rich Mockingbird(s), and a nasty attitude.

  • A nice, Utopian idea, but given that this would allow some company to build their own "Remotes", I don't see it being considered.


    It would be akin to shooting yourself in the foot. Only the Remote can do what the Remote does, and I don't see the company ever changing that.

    Nah, it's not that simple. Where there are risks, there are also opportunities.

  • That may be true, but I wouldn't bet on it. When you have created a successful ecosystem for your products, why share the spoils?

    It would eventually result in a fundamentally different business model. Microsoft sell operating systems which can be run on other people’s hardware. Apple sell a complete closed end “ecosystem”. Bothe can be successful bit I definitely see Kemper as the Apple model and don’t see them have any incentive to change.

  • It would eventually result in a fundamentally different business model. Microsoft sell operating systems which can be run on other people’s hardware. Apple sell a complete closed end “ecosystem”. Bothe can be successful bit I definitely see Kemper as the Apple model and don’t see them have any incentive to change.

    True. It is just to give an impulse towards that direction. :)