Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by nlate

  1. 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!


  3. 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
  4. 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. nlate

    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
  6. Dear Benoit Thank you very much for sharing your findings rel.to the ASX board! Kind regards Jo
  7. 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_FIO
  8. 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 inst
  9. 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
  10. 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): [
  11. nlate


    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
  12. Thank you very much, Thorsten! Best regards, Jo
  13. 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
  14. 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
  15. 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 adapt
  16. Hi Christian, I checked your adapter PCB and it seems to be correct. 2 possibilities, which can cause your troubles: 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. 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, Jo
  17. 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! Jo project.hex
  18. Dear Benoit 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, Jo
  19. Dear Thorsten, Acc. to your Message #46 That looks quite interesting and leads me to some questions: You mentioned 4 UARTs per chip, but I can only find 2 EUSARTs in the documentation. How do you intend to implement 4 UARTs? 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
  20. Dear Benoit Do you have any news on availability and price of OEM RTP-MIDI modules. Best regards, Jo
  21. 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 unde
  22. Hi Novski I use - Brenner8 (rev 4) described at http://www.sprut.de/electronic/pic/projekte/brenner8/ (this was a DIY Kit) - Brenner8P9smd von Lars described at the same Link (a ready to use device). Both work flawlessly without any issues. But I must say that I always must read the related manuals before using them, because they are seldom in operation since I went for MIOS 32 Nexpresso LXP1769 Regards, Jo
  23. Hi Novski, These parts are rubber mats from the Studer OnAir 2500 console. http://www.drwaguenther.ch/de/studer_42985_DEU_AS.html They can be ordered as spare parts from Dr.W.A.Günther: http://www.drwaguenther.ch/de/5820_DEU_AS.html Best regards, Jo
  24. nlate

    MIDIbox KB

    Dear Thorsten, Thanks for adding the release velocity to the repository, and for updating the documenation. 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){ expression(); } but makes a typo of: if( variable_x = CONST_A){ expression(); } 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){ expression(); } with the same typo: if( CONST_A = variable_x){ expr
  • Create New...