Posts by virango

    On such a page loaded with so much information, it could be an overload. My suggestion was tailored toward the idea of being able to load FX simply and make simple tweaks if necessary. Then, if deeper editing is required, double click on a loaded FX in order to bring up a pop up with all the parameters for that FX.

    Absolutely. My idea for the toaster editor is to have a main desktop window with a lot of dockable windows.


    Can you draw a sketch of what you imagine to be GUI layout?

    Just imagine a dockable window with a nice skin and a lot of knobs.

    but getting back to topic, I'm a bit confused as to why this thing would take that long when Toast, editor created by someone using his free time, got so far without actual support from Kemper. What I'm saying is that if The maker of Toast would get access or knowledge of the internal parameters exclusive to the Kemper that aren't obvious or public, he could very well have the whole thing finished in relatively a short period, and anyway these editors usually remain in Beta status almost forever from what I've seen from most companies. I wonder if the engineer they had spoken with is, the same who made "Toast"


    With a support from Kemper and working full time a skilled sw developer could make a decent editor in about half a year, I think. The estimated net effort I spent till yet developing Toaster is about 3-4 man-months. More than half of that time went to research.


    And no I’m not the one Kemper spoken to.

    IMHO an extra software editor will not come. A second application means more development/maintenance effort. Furthermore you have to add some sync mechanism as both applications (Rig Manager + editor) would access the same data.
    More likely the Kemper team will extend the Rig Manager, I think.


    As for the job@Kemper: it's surely a tempting possibilty. Unfortunately (currently) not an option for me.

    Hm, an editor would be a totally different ballgame... I definitely won't have the time or energy to start that adventure. Last week I did have a look at the "Toaster" editor which is in the works - a huge job, very well done... So here's my message to @virango : when "donating" the result of such a huge job on github, you should definitely consider to add a "Donate" button somewhere, even if it will never fully compensate for the many hours you must have already spent on this. I for sure will donate, even if I will never use the editor myself (not being a Kemper user...) I did gather the info about how stomp types relate to stomp LED colors by looking at your source code. Thanks and kudos to you...!

    You're welcome and thanks.

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

    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.

    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.

    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.

    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.

    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.

    On thing I would like to mention here if you or somebody continues work on this project - I think that resembling Kemper's interface 1:1 is not what more would want (at least me).


    I think that for example all FX, amp, cab etc parameters should exist on 1 page. The less clicking the better.

    You are surely right, I'm aware of that. Toaster has currently this one view, more could, should (and will) be added. For me it was important to make a proof of concept in the first instance. So I hoped to win over developers who want to participate. Also someone with graphical skills would help.

    What about this as starting point?

    No, Rig Manager will not run under Linux by just recompiling it. I have no idea what you think you saw in the resources, but SQLite is actually the only public domain library that is used by Rig Manager. The UI, which takes up ca. 30% of the code, is completely native on both platforms. I'm not a Linux developer, so I can't tell how hard it is to port managed code (for Windows Forms) or Objective-C (for Cocoa) to a Linux app, but I don't believe it is that easy.
    BTW, SQLite is mainly developed by paid full-time developers, so there is not really a community that we can give anything back to. Instead, we are giving Rig Manager to the Kemper community for free.

    What about the dxd - dynax driver framework? It claims also do be open source.

    Guys , it would be handy if performances would stay on the screen while browsing through rig. If you could then drag&drop them it would be very convenient. Now the copy&paste function is abit of a hassle . same goes for the preview function on the performances itself , clicking them will preview them instantly instead of selecting it from a dropbox

    You can open a second window: in the first you works on rigs in the second on performances. As far as I can remember drag&drop works from one window to another.