Linux Collaboration

  • Hi there,


    I'm an embedded Linux developer, with lots of experience with system code, cross platform code, pro audio, and UI solutions.


    I would be interested in implementing an open source USB driver (Rust or C) that works on Windows, Mac, and Linux. Possible UI client could be Flutter, QT, etc.


    I own a stage profiler.


    Is there any interest in a collaboration?


    Cheers,

    Joel Winarske
    https://github.com/jwinarske
    https://github.com/meta-flutter

  • So like an open source rig manager replacement? Or?

    Kemper PowerRack |Kemper Stage| Rivera 4x12 V30 cab | Yamaha DXR10 pair | UA Apollo Twin Duo | Adam A7X | Cubase DAW
    Fender Telecaster 62 re-issue chambered mahogany | Kramer! (1988 or so...) | Gibson Les Paul R7 | Fender Stratocaster HBS-1 Classic Relic Custom Shop | LTD EC-1000 Evertune | 1988 Desert Yellow JEM

  • I've had a quick look at the USB communication with Wireshark. I see the Kemper responding with, what looks like, a different serialization of the SysEx format documented in the MIDI manual.

    Here's the leftover data from a random URB_BULK input (I've seperated the bits that I think are serialization directives):

    Compare that with the layout of a SysEx message:


    $F0$00 $20 $33$02$7FMessage$F7
    SYXAccess/Kemper Manufacturer IDProduct Type $02 = Kemper ProfilerDevice ID $7F = OMNI (See System page)The actual messageEOX


    I'd have to figure out how to filter out all the chatter to get a better understanding. Plus I'm not super familiar with the USB protocol.

  • I logged USB via Wireshark this morning. I am targeting the following basic scenarios:
    1. Initial App connect to real time control "idle"

    2. App connect -> then Firmware update

    3. Connection post firmware update reboot -> real time control "idle" -> app close


    This should be enough to build a simple driver that has reliable connect/disconnect/communications, and provide basic real time control.

    The time investment will be around mapping commands/parameter changes/ranges; if different than midi mapping.

  • I have a basic cli app to start with:
    https://github.com/jwinarske/kemprof


    It mocks a rig manager connection, and receives real time packets from the profiler stage until closed.


    Example output
    ```

    $ ./profiler_cli

    Using libusb v1.0.25.11692

    Opening device 133e:0001


    Device properties:

    bus number: 3

    port path: 3 (from root hub)

    speed: 12 Mbit/s (USB FullSpeed)


    Device descriptor:

    length: 18

    device class: 0

    S/N: 3

    VID:PID: 133E:0001

    bcdDevice: 0100

    iMan:iProd:iSer: 1:2:3

    nb confs: 1


    Reading string descriptors:

    String (0x01): "Kemper"

    String (0x02): "Profiler"

    String (0x03): "..........."


    Configuration descriptor:

    total length: 46

    descriptor length: 9

    nb interfaces: 1

    interface[0]: id = 0

    interface[0].altsetting[0]: num endpoints = 4

    Class.SubClass.Protocol: FF.FF.FF

    endpoint[0].address: 01

    max packet size: 0040

    polling interval: 00

    endpoint[1].address: 81

    max packet size: 0040

    polling interval: 00

    endpoint[2].address: 02

    max packet size: 0040

    polling interval: 00

    endpoint[3].address: 82

    max packet size: 0040

    polling interval: 00

    04030904

    String (0x04): "APP=PROFILINGAMP"

    String (0x05): "OS=Release: 8.7.15.42312"

    String (0x06): "CPUID=XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX"

    String (0x07): "MAC=XXXXXXXXXXXX"

    String (0x08): "MGR={XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"

    String (0x09): "DEF={XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"


    Configuration: 1

    Interface claimed.

    [Rx.1] length:64, actual_length:4

    0x000000: fb b1 7f 01 ....


    [Rx.1] length:64, actual_length:4

    0x000000: fb b1 7f 01 ....


    [Rx.1] length:64, actual_length:36

    0x000000: 14 f0 00 20 14 33 00 00 14 07 00 00 14 00 0c 1a ... .3..........

    0x000010: 14 40 4d 79 14 50 72 6f 14 66 69 6c 14 65 72 00 [email protected].

    0x000020: 15 f7 00 00 ....


    [Rx.1] length:64, actual_length:40

    0x000000: 14 f0 00 20 14 33 00 00 14 07 00 00 14 00 0c 1a ... .3..........

    0x000010: 14 41 4a 6f 14 65 6c 20 14 57 69 6e 14 61 72 73 .AJo.el .Win.ars

    0x000020: 14 6b 65 00 15 f7 00 00 .ke.....


    [Rx.1] length:64, actual_length:20

    0x000000: 14 f0 00 20 14 33 00 00 14 01 00 7f 14 7d 00 00 ... .3.......}..

    0x000010: 15 f7 00 00 ....


    [Rx.2] length:64, actual_length:1

    0x000000: 78 x


    [Rx.2] length:64, actual_length:1

    0x000000: 9d .


    [Rx.2] length:64, actual_length:2

    0x000000: 6e 40 n@


    [Rx.2] length:64, actual_length:2

    0x000000: 32 27 2'


    [Rx.2] length:64, actual_length:1

    0x000000: e6 .


    [Rx.2] length:64, actual_length:1

    0x000000: 3f ?


    [Rx.2] length:64, actual_length:1

    0x000000: a8 .


    [Rx.2] length:64, actual_length:1

    0x000000: c0 .


    [Rx.2] length:64, actual_length:1

    0x000000: 01 .


    [Rx.1] length:64, actual_length:4

    0x000000: ee cd b7 0a ....


    [Rx.1] length:64, actual_length:4

    0x000000: ef 1d 50 be ..P.


    [Rx.1] length:64, actual_length:44

    0x000000: 14 f0 00 20 14 33 00 00 14 02 00 7c 14 4e 00 00 ... .3.....|.N..

    0x000010: 14 00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 ................

    0x000020: 14 00 05 00 14 00 00 00 17 00 00 f7 ............

    ```

  • Nice Work, i also tried a little bit to wireshark... but decided to do it with web technology...

    (the gui still has issues but should give an idea, atm. i will setup an npm app and implement a proper toolstack -> to use it in the browser, regardless of the OS but limited to midi)


    If you should find out the usb commands i could maybe benefit from it too (i didn't spend much time on it)


    https://github.com/schoko11/KEKO-WEB

    https://schoko11.github.io/KEKO-WEB/


    it scales with the screensize, and shows (and hide) gui elements depending on the size..

  • schoko After removing transport framing, and looking at your MIDI constants in . I'm now parsing 7-bit SysEx strings with SysEx ID equal to "Access Music Electronics". EP1 is "encoded" MIDI SysEx, not clear what EP2 is talking yet. Similar pattern as the ElevenRack.


    A snippet of parsed receive packets:


    A bit more work until I check that parsing in.

  • jwinarske

    I am not sure if i can follow...

    (EP1 is the part after "Access Music Electronics" and EP2 is after these,...?)

    Access Music Electronics is some kind of standard...


    As for Sysex messages and their length...

    you can request multi paramters, which is quite essential(when requesting paramter and fx.. you want so save calls, but have to do more work on the receiving side.. -> especially if you want to collect a whole rig)


    Did you record which action caused these messages, or is this at startup?

  • Search for "Access Music Electronics" in this link, and notice the byte sequence:
    https://www.midi.org/specifica…m/manufacturer-id-numbers


    The packet exchange I'm using is from Mac M1 USB Wireshark capture of RigManager connecting to Stage Profiler, wait until idle traffic, then close the RigManager. It syncs all of the parameters/strings/settings. The packets are in this header file:
    https://github.com/jwinarske/kemprof/blob/main/packets.h#L22

    The messages in this header are packed (more than one SysEx packet per USB bulk transfer in most cases) and it also includes a transport layer.

    I'm planning to add a simple command line shell to test sending and receiving of SysEx messages. The library will add the transport layer, and queue transfers on the bus. You would just type in the string of the SysEx packet, and it would print the SysEx response. This makes discovering the SysEx packet structure easier.

  • Looks like the function code data encoding matches the docs, the only difference is the function code response byte itself has swapped nibbles. Meaning the "functionality" of the function code response is determined by the high nibble - X0h. Lower nibble is fixed to 0h. Should be fairly straight forward to decode them all, as it's well documented in the MIDI manual.

  • You guys are awesome. Looking forward to whatever comes out it this. The only part I understood was nibbles though. Gotta love' em.

    Kemper PowerRack |Kemper Stage| Rivera 4x12 V30 cab | Yamaha DXR10 pair | UA Apollo Twin Duo | Adam A7X | Cubase DAW
    Fender Telecaster 62 re-issue chambered mahogany | Kramer! (1988 or so...) | Gibson Les Paul R7 | Fender Stratocaster HBS-1 Classic Relic Custom Shop | LTD EC-1000 Evertune | 1988 Desert Yellow JEM

  • I am at this point able to decode all the System Exclusive messages that happen as part of the RigManager exchange. Which the structure of all the packets are documented in the Midi guide. I'm printing out the raw (non-normalized) controller values.

    What's not clear yet is what the blobs are used for. Maybe a DSP cache state.

    Does anyone know of a hardware bill of materials (BOM) for the Profiler / Stage Profiler? I'm mostly interested in the SoC/CPU/DSP used.

  • I am at this point able to decode all the System Exclusive messages that happen as part of the RigManager exchange. Which the structure of all the packets are documented in the Midi guide. I'm printing out the raw (non-normalized) controller values.

    What's not clear yet is what the blobs are used for. Maybe a DSP cache state.

    Does anyone know of a hardware bill of materials (BOM) for the Profiler / Stage Profiler? I'm mostly interested in the SoC/CPU/DSP used.

    I have read something about motorola hardware, hopefully i remember correctly.


    As far as i know they just changed from 2019 models onwards something for the spdif hardware..(slave and master mode possible)


    Great progress!

  • Decoder stuff pushed. Next is to accept plain SysEx, add transport, and transmit. I'll refactor packets.h into logical SysEx packets as part of that process.

    It's not 100% stable yet, as I need to sort out how I want to do sync vs async packets.