Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by nlate

  1. Dear Thorsten
    Dear Benoit

    I try to integrate the KissBox RTP-MIDI OEM Module(KB OEM) in my MIDIbox (Core_LPC17) Masterkeyboard appl.

    What I already did:
    A. In the MIOS32 bootloader v1.018: "set spi_midi 1"

    B. In the KissBox Editor (V13)->Session Initiator control: Host Port   ""
                                                          Bonjour/Session name:                      "KB OEM Module@253 Port 1" (s. screenshot below)
       Result: The via LAN connected 3rd party RTP-MIDI device (iConnectivity Mio10 IP:
                    to the KB OEM Module shows the KB OEM Module "KB OEM Module@253 Port 1" as its 1st session.


    C. Setup of T. Erichsen´s "rtpMIDI" on Win10 x64,
       which acts as a Session Initiator between PC Midi-Apps (Session Initiator) and the Mio10 RTP Session Listener/Ports (max. 4 Sessions)

    My intension is to use te KB OEM module as bridge for my MIDIbox Masterkeyboard.
    Its Endpoint should mainly act as Session Initiator for connected RTP-MIDI devices (2x iConnectivity Mio10 & 1x iConnectivity iConnect MIDI4+)
    -> so max. 12 RTP sessions should be initiated by the KB OEM module WITHOUT the need of a computer (PC or Mac).
    The remaining 4 RTP sessions would be between the T. Erichsen's rtpMIDI app. as Session Initiator and the PC apps as Session Listener/Responder

    There arose several questions/open points.

    1. @BEBDigitalAudio: Is my intension above visible with the KB OEM module?

    2. @BEBDigitalAudio: KB OEM Firmware seems to be V2.1 shown at the KissBox Editor (s. screenshot of the KissBox Editor above).
       Is this the correct/recent FW you mentioned in:3. @TK.:  SPI Master/Slave role:

         CORE_LPC17 -> SPI Master ?
         KB OEM -> SPI Slave ?
         Correct ?

    4. @TK.: can the definition

    #define MIOS32_SPI_MIDI_NUM_PORTS 4

       in mios32_test/mios32_spi_midi/mios32_config.h
       be reduced to

    #define MIOS32_SPI_MIDI_NUM_PORTS 1

       if the SPI connection from CORE_LPC17 to KB OEM is the only used SPI connection?   

    5. @TK.: Does the related Session ID corespond to the cable ID in the 1st nibble of the 1 byte of the 4-byte 

     "mios32_midi_package_t midi_package"?

    6. How can the Core_LPC17 via KB OEM Module act as a Session Initiator for further Sessions apart form the 1st session at startup (s. screenshot mentioned in (B)?
        I suppose via SYSEX stream from CORE_LPC17 to KB OEM via SPI.
    6.1  @BEBDigitalAudio: Could you explain the protocol sequence for Session Initiator and the syntax details?

    7. How can the Core_LPC17 via KB OEM Module act as a Session Listener/Responder for Session Connection requests
        initiated by other members in the RTP MIDI network?
        I suppose via SYSEX stream from KB OEM  to CORE_LPC17 via SPI.
    7.1  @BEBDigitalAudio: Could you explain the protocol sequence for Session Listener and the syntax details?

    Thank you very much in advance for your answers and your endless support & enthusiasm for the MIDIbox community !!!!

    Best regards


  2. Hallo Rolf

    Wenn du R89 mit jeweils 10k auf die Multiplexereingänge X1 & X2 verschiebst, fällt nur eine geringe Spannung über dem Multiplexer ab, da der Multiplexerausgang bzw. der(-) Eingang von IC15b nahezu auf 0V. Dies kommt der Signalqualität deiner Einganssingnale zu Gute.



  3. Hi Christian

    I got the same issue during testing of my modifications of the code. Imho the reason for that is caused by the debouncing routines in the fct: KEYBOARD_NotifyToggle() e.g. the code
     // debounce processing
      if( kc->scan_velocity ) {
        if ( !kc->scan_release_velocity ) {

    The routine doesn´t check all possible states, which could occure if the naked keybed is just played on a table. During glissandos some keys can bounce back so quickly that they accidently retrigger the make contact.
    This effect is minimized on buildin keybeds by the (red) felt strip at the backend and near the turning point of the keys.
    My code with the modified debounce check is a) not error-free and b) not in a publishable condition.
    So I can´t fix your issue a.t.m.
    Sorry and regards,

  4. Hey,

    sometimes especially when doing a glissando I get stucking notes. I can avoid this by using MIDIbox NG and set the number of shift registers to a higher value f.e. 6 or 8. But this on the other side lowers the velocity-resolution and I normally want to use the KB app for the keyboard. Do you have also those problems? I have that with different keybeds (all FATAR).

  5. Dear Thorsten

    Thanks for your reply.

    During further investigation related to the RI_N topic I found the following issue in mios32\common\mios32_iic_midi.c:

    #elif defined(MIOS32_FAMILY_LPC17xx)
    #if MIOS32_IIC_MIDI0_ENABLED == 3
      MIOS32_SYS_LPC_FIODIR(MIOS32_IIC_MIDI0_RI_N_PORT, MIOS32_IIC_MIDI0_RI_N_PIN, 0); // <-- This function/macro doesn´t excist !!
    #if MIOS32_IIC_MIDI7_ENABLED == 3


    also at

    # elif defined(MIOS32_FAMILY_LPC17xx)
        case 0: return MIOS32_SYS_LPC_FIOGET(MIOS32_IIC_MIDI0_RI_N_PORT, MIOS32_IIC_MIDI0_RI_N_PIN) ? 0 : 1; // <-- This function/macro doesn´t excist !!
    # elif defined(MIOS32_FAMILY_LPC17xx)
        case 6: return MIOS32_SYS_LPC_FIOGET(MIOS32_IIC_MIDI6_RI_N_PORT, MIOS32_IIC_MIDI6_RI_N_PIN) ? 0 : 1;


    I replaced

    MIOS32_SYS_LPC_FIODIR() with the MIOS32_SYS_LPC_PINDIR() macro



    and replaced

    MIOS32_SYS_LPC_FIOGET() with the MIOS32_SYS_LPC_PINGET() macro


    The app at Mios32\apps\troubleshooting\iic_midi compiled and linked successfully afterwards!

    The related Port (J10 on the LPC17 booard) was also found. It is defined in:
    Mios32\include\mios32\mios32_iic_midi.h, where Port J10 D0..7 relates to RI_N ICC 1..8

    I Modified the Mios32\apps\troubleshooting\iic_midi\mios32_config.h:

    #define MIOS32_IIC_MIDI0_ENABLED 3


    and connected the IIC_MIDI Module with your firmware and RI PIN connected and it behaves correctly as with simple IIC Port polling!

    could you agree that my assumptions are correct?

    Best regards,

  6. Dear MIDIBOXers,

    During integration of my IIC_MIDI hardware module I run into an issue of using the RI_N_PINs.
    Just some simple questions:
    To which PORT and PINs are this inputs assigned ?

    1. On the old STM32F0x based PCB
    2. On my current LPC17 based PCB
    3. On the new STM32F4 based PCB

    In the mios32_config.h there only seems to be mentioned the old STM32F0x scheme,

    which uses the J5C for RI0..RI3 and J5A for RI4..7.
    If these Port Pins would actually used as Inputs for signalling in case a MIDI Message was received the _ENABLED flag should be set to:

    3 = interface enabled, check RI_N pin instead of polling receive status


    #define MIOS32_IIC_MIDI0_ENABLED    2
    #define MIOS32_IIC_MIDI0_RI_N_PIN   GPIO_Pin_0
    #define MIOS32_IIC_MIDI7_ENABLED    2
    #define MIOS32_IIC_MIDI7_RI_N_PIN   GPIO_Pin_3

    How has this mios32_config.h file to be modified ?

    1. for the LPC17 core
    2. for the STM32F4 core

    What are the Port and Pin Names ?

    1. on the LPC17 core based PCB
    2. on the STM32F4 core based PCB

    Thanks in advance for your advice & support and best regards,

  7. Dear Thorsten,


    Could you please explain how the "hacked firmware" works.    http://ucapps.de/midibox_seq_manual_hw.html 


    I have ordered 2xQuad IIc + 8x16f88 from Tim, and asked him to burn them with this "hacked firmware", but he didn't know about it.


    If I understand it correctly, I can have 12 MIDI OUT on the Seq 4 on STM32F4, 4 from 2x MBHP_MIDI_IO boards chained on J11E, and 8 from 2xQuad IIc boards connected to J4A and J4B.


    Is the hack on the IIc firmware on the PIC's, or in the Seq 4 firmware, or both?


    Best regards, Hal

    Hi Thorsten, I´m also intrested in this "Firmware Hack" rsp. how to implement this on the PIC 16F88 side.

    Thanks in advance and best regards,


  8. Dear Thorsten, dear MIDIBOXers

    First of all Happy New Year 2015!

    During regression tests of the midibox_kb_v1 project I found a nasty bug in
    SVN.MIOS32\trunk\modules\keyboard\keyboard.c at the KEYBOARD_NotifyToggle() fct.:

    // released key ?
    if( depressed ) {
    [L578]: s16 delay = *ts_break_ptr - *ts_make_ptr;



    } else {
    // pressed key ?
    [L631]: s16 delay = *ts_make_ptr - *ts_break_ptr;

    the (signed short) variable s16 delay leads to the following behaviour during delay calculations in case of overrun

    (s. 2nd & 3rd line during a debug session):

    [18721.553] Released: s16 delay= 17982 = u16 ts_break=58069 - u16 ts_make =40087
    [18796.922] Pressed : s16 delay= 24956 = u16 ts_make =14748 - u16 ts_break=55328
    [18817.231] Released: s16 delay=-20449 = u16 ts_break=40161 - u16 ts_make =60610 /!\



    the 2nd line is still correct because the subtraction doesn´t exceed the positive range of the (signed short) s16 delay range.
    the 3rd line is mathematically correct, but not from the applicational view point.

    The local fct.:

    [L802]: static int KEYBOARD_GetVelocity(s16 delay, u16 delay_slowest, u16 delay_fastest)

    doesn´t handle negative delay values correctly because it handles all values below delay_fastest as max. velocity!

    So I changed the delay values in line 578, 631 & 802 from  s16  to u16 with the result that the overrun case is now handled correctly:

    Released: u16 delay= 17982 = u16 ts_break=58069 - u16 ts_make =40087
    Pressed : u16 delay= 24956 = u16 ts_make =14748 - u16 ts_break=55328
    Released: u16 delay= 45087 = u16 ts_break=40161 - u16 ts_make =60610


    Thorsten, would you be so kind to check if my findings are correct, and make the proposed changes in

    modules/keyboard/keyboard.c  and in apps/tutorials/029_keyboard_velocity/app.c if you confirm.

    Thanks and best regards,

  9. Christian,

    It is not only SW you also need additional HW (HC595) because you have to scan BR0..10 and MK0..10 = 22 scan lines.

    This means 3 Shift registers. This can't be done with 1DIO Module.

    On my TP9 there are a lot of bridging wires (Loetbruecken), may be the bridging on TP100 between LH and RH T0..7 is also achieved in the same manor.



  10. Hi Christian

    The connections Fatar (StudioLogic) uses, seems to be related to a 8-Bit microcontroller. E.g. BR0 & BR5 can not be scanned in the same scan run because L & R Return Lines (T0..7) are tied together. This doubles the scan runs.

    Instead of BR0/5,...., BR4/9, BR10 and reading LH T0..7 & RH T0..7 as one 16-Bit value you have to scan BR0 and reading T0..7, BR1 and reading T0..7, etc.

    If You see a chance to cut the connections between the LH and RH T0...7 in your recent schematic , you can use the DIO with the Connection scheme for the 88 Key TP8/9 keyboard. (Your adapter PCB shown at 2014-08-20)



  11. Hi Christian,


    I checked your adapter PCB and it seems to be correct.


    2 possibilities, which can cause your troubles:

    1. Fatar has changed the pinning of the right half of the scan matrix on the TP100 keyboard
      The scan matrix schematic relates to TP/8/9.
    2. The top right ribbon cable Connector _TO_JP2 is plugged in reverse order.
      (I know, it is a very stupid idea, but it may be worth for a try)

    Best regards,


  12. Hi Christian,


    I just re-compiled the latest MIDIboxKB V1.013 out of my latest SVN Rev.2034 and installed it on my testbed LPC17 with the Fatar TP9 (88 keys) and it works as expected.

    I checked all settings in MiosStudio -> o.k.

    I checked all 88 Keys about their correct notes -> o.k.


    Maybe my project.hex will help. Settings are according to MiosStudio screenshot.

    If this doesn´t help then your TP100 scanmatrix or your DIN/DOUT connectiion is different from the one Thorsten proposed on his Keyboard project page.


    Good Luck!




  13. Dear Benoit

    Hi Jo,


    yes, here are the latest news : a new batch of boards is leaving the factory today, so they are now available for sales.

    Concerning the price, let me check today with my business partner if we keep or change the price (we have made a slightly bigger production this time, so the price can be readjusted)



    Thank you for this infromation.

    Do you intend to inform about availability and price:

    1. Here in this Midibox thread or

    2. under Midibox bulk orders or

    3. at the Kissbox.nl site ?


    looking forward having the RTP-OEM boards in my hand :rolleyes:

    Best regards,


  14. Dear Thorsten,


    Acc. to your Message #46


    If more than 4 IIC_MIDI based IOs are desired, it makes sense to think about a redesigned version of the MBHP_IIC_MIDI module, which gets use of a microcontroller with more UARTs.


    E.g. the PIC18F25K22 comes in a small 28-pin DIP package, contains 4 UARTs and is available for 2.55 EUR at Reichelt: http://www.reichelt.de/PIC-18F25K22-ISP/3/index.html?&ACTION=3&LA=446&ARTICLE=109911


    That looks quite interesting and leads me to some questions:

    1. You mentioned 4 UARTs per chip, but I can only find 2 EUSARTs in the documentation. How do you intend to implement 4 UARTs?
    2. Is it possible to access each of the 2 UARTs with a dedicated IIC 7 bit adress with the aid of the SSPx Mask register?

    As you may remember I already started an enhanced IIC -> MIDI implementation some years ago. I will not define a new IIC protocol again, so accessing the 2 UARTs with separate IIC addresses would minimize the protocol changes.

    Thanks in advance for your answers
    Best regards,

  15. Dear All


    First I want to thank Benoit for making available this RTP-OEM module to the MIDIbox community in small quantities.

    Additional credits go to Thorsten as usual for his enthusiasm making RTP-MIDI available to us as I/O option on MIOS32 projects in near future.


    Some personal opinions regarding the discussion on the price of the RTP-OEM module:

    • 90-100 Euros seems not to be a snap for the MIDIBox community.
      But you will get a fully compliant RTP-MIDI frontend, which can be easily accessed by any user application.
      It took me one week of my holidays several years ago just to understand the specified mechanisms of this powerful transport protocol.
    • I thought: “Well, I understand how to implement the base protocol without the journaling mechanism on a MIOS32 based controllerâ€.
      The problems arose as soon as I thought about the implementation of the proposed Session Initiation Protocol (SIP).
      The RTP-MIDI specs touch this issue only briefly in its implementation notes and refers to the SIP specs.
    • Which company actually use SIP for RTP-MIDI for connectivity? -> None!
    • How did Apple, the most known implementer of RTP-MIDI, initiate a RTP-MIDI session? -> No Idea!
      I was not in the mood to use Etherreal  aka. Wireshark to spy out the Session start and close mechanism, apart from digging through the Bonjour stuff.

    So, I will be very happy to get a module which keeps me away from such network issues.

    I understand that Benoit resp. Kissbox could not give away this for prime/material costs taking in account the huge amount of SW for RTP-MIDI implementation

    Imho 90-100 Euros is still a bargain for such a device with this functionality including Session Initiation, RTP-MIDI and Journaling.



    1. Thorsten mentioned that TCP/IP is used as lower layer transport protocol.
      Afaik RTP-MIDI uses UDP with the journaling mechanism for resilence and robustness.
      All PC-Hosts (PC/Apple) implement RTP-MIDI communication over IP via UDP.
      What is actually used?
    2. Benoit/Kissbox talks in their RTP-MIDI OEM board announcement (http://www.kissbox.nl/products_oem.html)  about “Up to 8 RTP-MIDI sessions in parallel†resp. 8 MIDI I/O pairs.
      Thorsten’s Post #24 mentions:
      “…and can confirm that the sessions can be routed to different "virtual cables", so that they are accessible as RTP1..RTP16…â€
      Are these RTP1..RTP16 connections unidirectional, so two of them are needed per Session?

    Best regards,


  16. Dear Thorsten,

    Thanks for adding the release velocity to the repository, and for updating the documenation.


    One thing puzzles me a bit: why are you writing "0xff == prev_row" instead of "prev_row == 0xff"?

    Both expressions should be equal, but the original expression is better to read (from my point of view)


    This is a result of experience with hard to find bugs in production quality code.

    suppose the coder intents to write:

    if( variable_x == CONST_A){

    but makes a typo of:

    if( variable_x = CONST_A){

    both variants are valid c code, and rarly generate wrong results, if the variable_x has the value CONST_A most of the time!

    if you write:

    if( CONST_A == varable_x){

    with the same typo:

    if( CONST_A = variable_x){

    you will get a compiler error, and your typo is easily detected by the compiler!

    Just my two cents for writing robust code.


  17. Dear Thorsten,
    Dear MIDIBOXers

    During the recent weeks I extended the midibox_kb project for detecting also
    release velocity if the keybed is able to detect it like the FATAR DF xx types.

    Additionally EEPROM preset system is also extended to cope with the additional parameters.

    Initially I also revised the parameter documentation on http://ucapps.de/midibox_kb.html and I propose some minor additions/corrections for the FATAR DF type keybeds:

    - set kb <1|2> note_offset <0-127>:
      21 for 88 keys (a-1);
      28 for 76 keys (E-0);
      36 for 61 keys & 49 keys (C-1);
      48 for 25 keys (C-2)
    - set kb <1|2> din_key_offset <0-127>:
      32 for 61 keys and 76 keys;
      40 for 88 keys ;

    The below proposed code changes/additions don´t generate noticable performance losses during my testing with a FATAR DF TP9/88 keybed.
    But I´m not completely sure if the changes behaves as expected with other separate Break/Make contact keybeds.
    So feel free to use inspect the code in your MIDI_KB project.

    typedef struct {
      u8  scan_release_velocity:1;
      u16 delay_fastest_release;
      u16 delay_fastest_release_black_keys;
      u16 delay_slowest_release;
    } keyboard_config_t;


    // removal of:
    static u8 key_note_on_sent[KEYBOARD_NUM][KEYBOARD_NUM_PINS / 8];
    static u8 key_note_off_sent[KEYBOARD_NUM][KEYBOARD_NUM_PINS / 8];
    // not used anymore (s. below)
    s32 KEYBOARD_Init(u32 mode)
      init of the additional structure members (s. above)
    void KEYBOARD_SRIO_ServicePrepare(void)
      // modified increment timestamp for velocity delay measurements
      // but skip 0, which is used as reset of  *ts_make  and *ts_break values
       if ( !(++timestamp))
    void KEYBOARD_SRIO_ServiceFinish(void)
    // use of timestamp ptrs instead of values
      u16 *ts_ptr = (u16 *)&din_activated_timestamp[kb][prev_row * MATRIX_NUM_ROWS];
      *ts_ptr == 0 // as additional condition to get updated in the for(..) loops
    // additional for(..) loop to handle release timestamps
    static void KEYBOARD_NotifyToggle(u8 kb, u8 row, u8 column, u8 depressed)
    // modified debounce processing
    // check for *ts_break_ptr and *ts_make_ptr instead of *note_on_sent and *note_off_sent
    // all access to the content of timestamp pointers is secured by
    // black key handling modified depending on kc->note_offset because this
    // offset determs the key to normalized note and not to the evtl. transposed MIDI note.
    // not every keybed starts with ´C´!
    // branch depending on pressed or released key
    // additional released key processing
    // additional help fct.:
    static int KEYBOARD_GetVelocity(s16 delay, u16 delay_slowest, u16 delay_fastest)
    // modified help fct. with additional parameter u8 depressed
    static s32 KEYBOARD_MIDI_SendNote(u8 kb, u8 note_number, u8 velocity, u8 depressed)
    // additional release velocity dependent parameters in:
    s32 KEYBOARD_TerminalHelp(void *_output_function)
    // and
    s32 KEYBOARD_TerminalParseLine(char *input, void *_output_function)
    // and
    s32 KEYBOARD_TerminalPrintConfig(int kb, void *_output_function)

    In MIOS32\apps\controllers\midibox_kb_v1\src\presets.h:

    // additional offset definitions at the end of:
    // and

    In Mios32\apps\controllers\midibox_kb_v1\src\presets.c:

    // modified fcts:
    s32 PRESETS_Init(u32 mode)
    // added bit at the end!
      kc->scan_release_velocity = (misc & (1 << 4)) ? 1 : 0;
    // added parameters at the end!
      kc->delay_fastest_black_keys         = PRESETS_Read16(PRESETS_ADDR_KB1_DELAY_FASTEST_BLACK_KEYS + offset);
      kc->delay_fastest_release            = PRESETS_Read16(PRESETS_ADDR_KB1_DELAY_FASTEST_RELEASE + offset);
      kc->delay_fastest_release_black_keys = PRESETS_Read16(PRESETS_ADDR_KB1_DELAY_FASTEST_RELEASE_BLACK_KEYS + offset);
      kc->delay_slowest_release        = PRESETS_Read16(PRESETS_ADDR_KB1_DELAY_SLOWEST_RELEASE + offset);
    s32 PRESETS_StoreAll(void)
    //added bitfield at the end!
      u16 misc =
        (kc->scan_release_velocity << 4);
      status |= PRESETS_Write16(PRESETS_ADDR_KB1_MISC + offset, misc);
    //added parameters at the end!
      status |= PRESETS_Write16(PRESETS_ADDR_KB1_DELAY_FASTEST_BLACK_KEYS + offset, kc->delay_fastest_black_keys);
      status |= PRESETS_Write16(PRESETS_ADDR_KB1_DELAY_FASTEST_RELEASE + offset, kc->delay_fastest_release);
      status |= PRESETS_Write16(PRESETS_ADDR_KB1_DELAY_FASTEST_RELEASE_BLACK_KEYS + offset, kc->delay_fastest_release_black_keys);
      status |= PRESETS_Write16(PRESETS_ADDR_KB1_DELAY_SLOWEST_RELEASE + offset, kc->delay_slowest_release);

    Have fun :rolleyes:





  • Create New...