Open source SDK for KPA

  • So my idea is to create open source SDK for KPA. For example using this SDK third party developers could

    • create their own effects,
    • create new stomp box simulations
    • create specific sounds using already existing stomp boxes

    Developers could share those plugins on Kemper site just like profiles. Of course I'm not shure that this feature could be implemented,
    but I think this feature can show KPA to users as open platform for creating their own sound.

  • Great great idea , but no chance of ever see it IMO , If CK had this in his projects , he would have published the specs and a minimal driver.


    Open Source projects can start with this minimal package, or by reverse engineering.


    Not to mention the risk of the Hardware technology beeing copied and sold at a fraction of the price...


    I sometimes dream about the time the KPA will be a fully opened platform with tons of hacks/new drivers/ third party softs ...


    Look at Apple, they had to wait for Job's death and 35 years to release the source code of the great Apple II, 35 years ?(

  • I've made the same suggestion elsewhere. I think it will happen. It would make the KPA a lot more useful and users would get editors, librarians, etc. Keep the interest up and it will happen. KPA already has a bigger eco-system than any other modeler by virtue of its growing list of profiling content providers. If the SDK was developed it would reduce the pressure on Kemper's software team and further its market penetration. Letting Kemper focus on better profiling tech and the underlying KAOS. A win-win. Patents will protect any 'copying and selling at a fraction of the price' IMO. I'm pretty happy with the device as is with the exception of a librarian. Editors are less important to me and could even be an update to the librarian. But if the SDK were available it would speed to market many solutions that Kemper may never think about or get to. Definitely something for Kemper to consider.

  • My personal opinion is: It won't happen.
    And I think it's not due to an overly protective mindset @ Kemper. But I could imagine 2 other reasons:


    1. Workload @ Support:
    Kemper can't offer support for user generated additions to the feature set. But still they would have an increase in support requests ... or at least more work to figure the cause of user problems. At least one more step to exclude unsupported causes.


    2. Future features (Kemper Profiler II):
    I can well imagine that with ever increasing processing power, it will be possible to run multiple profiles in one box at the same time. This could lead to real stomp box profiling, end of modelling in the STOMPS section. CK wouldn't be CK if he hadn't already thought about these things ... and why should he invest a lot of manpower in the development of an SDK, while he could make better use of the manpower to extend on a future version of the Profiler that would immediately make user programmed modelling obsolete (with the exception of time based effects, of course, that's another story).


    But as always, that's just my personal guess. ;)

  • There is no protection issue in publishing a SDK. A SDK is not the source code of the Kemper, but a set of API's to communicate 2-ways with the Kemper.
    It's just a matter of will, and a bit of work of course but probably not too much compared to what it would offer to the community.
    I already asked for it too, and think it would definetely be a good move.