nlate

Programmer
  • Content count

    68
  • Joined

  • Last visited

Community Reputation

0 Neutral

About nlate

  • Rank
    MIDIbox Newbie
  • Birthday 04/30/1959

Profile Information

  • Gender Male
  • Location South Germany
  • Interests MIDI, Audio, HUIs, Keyboards
  1. MIDIbox goes RTP-MIDI...

    Hello Benoit Thanks for responding I read and answered on your private message. I will report on further findings in this forum as soon as I will have further results with the KB OEM module connected to my MIDIBOX LPC17 Best regards, Jo
  2. Hi Benoit

    I just sent you some questions related to the KissBox RTP-MIDI OEM Module. It would be nice if you could answer some of them.

    Thanks in advance and best regards!

    Jo

  3. MIDIbox goes RTP-MIDI...

    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   "172.24.50.210:5004"                                                       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:172.24.50.210:5004)                 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 Jo
  4. AVR-Synthesizer "WAVE 1"

    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. Gruss Jo
  5. MIDIbox KB

    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, Jo
  6. MIDIbox KB

  7. The NG and the DSP...

    Dear Benoit   Thank you very much for sharing your findings rel.to the ASX board!   Kind regards Jo
  8. 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_PINSEL(MIOS32_IIC_MIDI0_RI_N_PORT, MIOS32_IIC_MIDI0_RI_N_PIN, 0); 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 MIOS32_SYS_LPC_PINSEL(MIOS32_IIC_MIDI7_RI_N_PORT, MIOS32_IIC_MIDI7_RI_N_PIN, 0); MIOS32_SYS_LPC_FIODIR(MIOS32_IIC_MIDI7_RI_N_PORT, MIOS32_IIC_MIDI7_RI_N_PIN, 0); .....   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, Jo  
  9. 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 ? On the old STM32F0x based PCB On my current LPC17 based PCB 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 Right? #define MIOS32_IIC_MIDI0_ENABLED 2 #define MIOS32_IIC_MIDI0_RI_N_PORT GPIOC #define MIOS32_IIC_MIDI0_RI_N_PIN GPIO_Pin_0 .... .... #define MIOS32_IIC_MIDI7_ENABLED 2 #define MIOS32_IIC_MIDI7_RI_N_PORT GPIOA #define MIOS32_IIC_MIDI7_RI_N_PIN GPIO_Pin_3 How has this mios32_config.h file to be modified ? for the LPC17 core for the STM32F4 core What are the Port and Pin Names ? on the LPC17 core based PCB on the STM32F4 core based PCB Thanks in advance for your advice & support and best regards, Jo
  10. 11 Midi Out Ports on MidiBox Seqv4

    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, Jo
  11. 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; ..... and   } 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 /!\ :sad:   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 :rolleyes: 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, Jo  
  12. MB-Sid-KeyBoard

    Hi Acul, Die MIDI Ports stellst du wie folgt ein: set kb1 midi_ports 0x0071 D.h 0 OSC Ports, 0 I2C ports, MIDI UART Ports 1-3, USB MIDI Port 1. Gruß Jo
  13. Thank you very much, Thorsten!   Best regards, Jo
  14. Dear Thorsten, I have the Impression that the SVN Mios32 repository has an older State (2086) than the most recent one (2088). Just for your info. Best regards, Jo
  15. din_key_offset not working on NG/KB?

    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. Regards, Jo