Jump to content

nlate

Programmer
  • Posts

    68
  • Joined

  • Last visited

Everything posted by nlate

  1. nlate

    MIDIbox KB

    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: e.g: - 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. Mios32\modules\keyboard\keyboard.h: typedef struct { ..... u8 scan_release_velocity:1; ..... ..... u16 delay_fastest_release; u16 delay_fastest_release_black_keys; ...... u16 delay_slowest_release; ...... } keyboard_config_t; Mios32\modules\keyboard\keyboard.c: // 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)) ++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 MIOS32_IRQ_Disable(); .... MIOS32_IRQ_Enable(); ... // 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: .. #define PRESETS_ADDR_KB1_DELAY_FASTEST_BLACK_KEYS (0xd1 + 0*PRESETS_OFFSET_BETWEEN_KB_RECORDS) // 0xd1 #define PRESETS_ADDR_KB1_DELAY_FASTEST_RELEASE (0xd2 + 0*PRESETS_OFFSET_BETWEEN_KB_RECORDS) // 0xd2 #define PRESETS_ADDR_KB1_DELAY_FASTEST_RELEASE_BLACK_KEYS (0xd3 + 0*PRESETS_OFFSET_BETWEEN_KB_RECORDS) // 0xd3 #define PRESETS_ADDR_KB1_DELAY_SLOWEST_RELEASE (0xd4 + 0*PRESETS_OFFSET_BETWEEN_KB_RECORDS) // 0xd4 ... // and ... #define PRESETS_ADDR_KB2_DELAY_FASTEST_BLACK_KEYS (0xd1 + 1*PRESETS_OFFSET_BETWEEN_KB_RECORDS) // 0xf1 #define PRESETS_ADDR_KB2_DELAY_FASTEST_RELEASE (0xd2 + 1*PRESETS_OFFSET_BETWEEN_KB_RECORDS) // 0xf2 #define PRESETS_ADDR_KB2_DELAY_FASTEST_RELEASE_BLACK_KEYS (0xd3 + 1*PRESETS_OFFSET_BETWEEN_KB_RECORDS) // 0xf3 #define PRESETS_ADDR_KB2_DELAY_SLOWEST_RELEASE (0xd4 + 1*PRESETS_OFFSET_BETWEEN_KB_RECORDS) // 0xf4 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: Regards, Jo Midibox_kb_relVelocity.zip
  2. Thanks Thorsten, I totally agree with your concerns, it´s not worth to change the stable and aproved MIOS32 framwork, for such a minor nice-to have feature. I may consider it, if I got all my other planned features for the MIDIboxKB project implemented and tested. Thanks anyway for your profund answers. Cheers, Jo
  3. Hi Thorsten, Many thanks for your quick answer! I totaly aggree to your constrains by the limitations of the bootloader. Is it possible and how to redirect the enumbered logical 4 USB ports 0..3 in the MIOS32 apps to the USB Pipes 1..4 instead of USB Pipe 0..3? Best Regards, Jo
  4. Dear MIDIBOXers, How can MOIS Studio access the LPC17 core exclusively via USB GM5 Port 5 instead of Port 1? #define MIOS32_MIDI_DEBUG_PORT USB4 in MIOS32_config.h only sends debug outputs on Port 5 (MIDI IN: GM5 Port 5 in MIIOS Studio) I want use Port 5 ( MIDI IN & OUT) as a service channel for MIOS Studio (MIOS Terminal, MIDI Monitor, Upload Window etc.). I would use Port 1..4 for pure application related MIDI data only. I this possible, and if yes, how could I achieve that? Where else do I have to make changes in the MISO32 framework? Thanks in advance! Cheers Jo
  5. nlate

    MIDIbox KB

    Dear Thorsten I updated my MIOS32 folder to the current Rev. 1663, built the project as always with the MIOS32 Toolchain under WinXP, installed the firmware with MIOS Studio and started the KB V1.008: The aforementioned crashes didn´t occur anymore over the whole keyrange!!! Thank You very much! I agree with all points you mentioned! Your question about delay_slowest: Yes, I mean the same value for both black and white keys. Fixed means imho that it depends only on the Users preferences, how much latency he would accept for NoteOn generation (about 31,7 ms in my example). Imho it´s not dependent on the actual keybed. Thanks again and regards Jo
  6. nlate

    MIDIbox KB

    Dear Thorsten Thanks in advance for your investigations. In the meantime I made some measurements with my USB logic analyzer. They may be helpful for the MBKB project documentation. I attached them as screenshots, the titles are hopefully self-explainining. MBKB_1RowScan.jpg Detail, how the Dout registers are controlled for one row. MBKB_ScanNonOptimizedOnly.jpg Timing for non optimized row scan without key press MBKB_ScanOptimizedOnly.jpg Same as above but with optimized row scan MBKB_ScanNonOptimizedC-0pressed.jpg Timing for 1 Key press C-0 non optimized scan MBKB_ScanOptimizedC-0pressed.jpg Same as above but with optimized scan MBKB_ScanOptimizedC-0_D-3pressed.jpg 2 keys pressed on Left and Right half of the 88 key Fatar keyboard with optimized row scan. MBKB_ScanOptimizedLhRhChordPressed.jpg 6-key Cord press with optimized row scan I also added the timing files in the zip archive the can be viewed in with the Analyzer SW available at http://www.pctestinstruments.com/downloads.htm running in Demo mode Best regards Jo MBKBtimings.zip
  7. nlate

    MIDIbox KB

    Dear Thorsten I successfully installed the precompiled MIDIBOX_kb_V1_007 .hex file on my LPC17xx system. Everything worked as expected: Terminal commands etc. Keyboard setup for Fatar DF88 Keyb. Minor issue: set kb 1 note_offset 24 (C-0) should be 21 (a-1) optimize option works perfect: 180 (6*30) us for a all 88 keys in steady state !!! 360 (12*30) us if all Dins (lower & upper half) change at once (very rarely)! some ideas and findings: delay_fastest should be made separate for white and black keys, because the lever of the black keys is shorter than the lever of the white keys. With the Fatar TP9-88 I could generate shortest delay of 40 ticks on black keys, with the white ones I never came under 57 ticks. delay_slowest can be made fixed, since it determines the latency of the sent MIDI cmd, eg. delay_slowest = delay_fastest + 127 * 8 => 31,7 ms latency. kc->break_inverted seems not to be initialized in KEYBOARD_Init(). In fct: void KEYBOARD_SRIO_ServicePrepare(void) which is called every 30 us: // optional scan optimization for break/make: if break not active, we don't need to scan make if( kc->scan_velocity && !kc->break_inverted && kc->scan_optimized ) {... // can ber replaced by : if( kc->scan_optimized ) { ... If the remaining conditions are checked in KEYBOARD_Init() and the related Set_..() functions Before I intended to modify the code, I build the project from the Reposity with Rev 1633 and loaded it into the platform. Everything went as expected until I pressed one of the two rightmost keys (B-6 & C-7): The System crashed with "!! HARD FAULT !! at PC = 0x000064d8" Since I haven´t any debugger I decided to go the hard way and did some version comparisons... I went back to Rev 1632 which was the the revision of your Build V1.007 and everything works without crashes. I checked the differencies to Rev 1633 and found out that app_lcd for universal lcd was changed, but this should not have any influence on the code. But then I realized that the terminal.c code was updated for all apps except for the Keyboard. So after modifying terminal.c the crashes were gone. I´m not 100% sure if I made the changes at the right places in terminal.c, so it would be fine if you can review the attached terminal.c and update the repository Thanks very much and best regards Jo terminal.zip
  8. nlate

    MIDIbox KB

    Hello Thorsten, Could you please also check the df88 interconnection Diagram in the documentation acc. to my former post #8 in: Thanks Jo
  9. Dear MidiBx community I switched over to Eclipse based MIOS32 toolchain according to the well written doku at: http://www.midibox.o....php?id=eclipse Set the Window->Preferences->C/C++->Built->Environment variables I also set the Windows Environment variables to: set MIOS32_PATH=/G/mios32 set MIOS32_BIN_PATH=/G/mios32/bin and set MIOS32_GCC_PREFIX=arm-none-eabi set MIOS32_FAMILY=STM32F10x set MIOS32_PROCESSOR=STM32F103RE set MIOS32_BOARD=MBHP_CORE_STM32 set MIOS32_LCD=universal according to http://www.midibox.o..._toolchain_core When I built my project I always get a bunch of warnings like: Invalid project path: Include path not found (\G\mios32\FreeRTOS\Source\include). midibox_kb_v1 pathentry Path Entry Problem But the compilation outputs project.hex successfully and it can be downloaded and run on the target device. How can I avoid these nasty warnings? Sugestions and help welcome! Thanks in advance Jo
  10. Dear Thorsten, Could you please also check/correct the:Fatar DF88 interconnections The interconnections between left & right side 20-Pin MicroMatch connectors seem to be incorrect. Imho it should be: Green lines (MKx): J3,O7 -> MK0 -> MK5 J3,O5 -> MK1 -> MK6 J3,O3 -> MK2 -> MK7 J3,O1 -> MK3 -> MK8 J4,O7 -> MK4 -> MK9 (already correct) J4,O5 --------> MK10 (already correct) Red lines (BKx): J3,O6 -> BK0 -> BK5 J3,O4 -> BK1 -> BK6 J3,O2 -> BK2 -> BK7 J3,O0 -> BK3 -> BK8 J4,O6 -> BK4 -> BK9 (already correct) J4,O4 --------> BK10 (already correct) Thanks for the fantastic KB project! Best Regards Jo
  11. Hallo Brathering Ich glaube nicht, dass beim ICON iStage Piezos eingesetzt werden. Ich vermute mal, dass es nach dem selben Prinzip wie Korg NanoPad, NI Machine und Akai MPC... arbeitet. Dabei wird die Anschlagstärke mit Hilfe von PSRs bestimmt. (s. mein Post #67 in diesem thread) Die PSRs unter den Pads sind in einer Matrix angeordnet und werden mit einem ADC ausgewertet. Gruss Jo
  12. Hallo Brathering Vielleicht habe ich das dann falsch verstanden: Ich dachte, es ginge darum, das NanoPad via USB an das MIDIBOX board LPC17 (mit NXP controller) anzuschliessen, um vom MIDIBOX controller das NanoPad als weiteres Eingabe Medium (vgl. Keyboards) zu nutzen, was so definitiv nicht geht (USB Device NanoPad <--> USB Device LPC17) Sorry für die Verwirrung! Gruss, Jo
  13. Hallo Frank Das mit dem USB Hub geht leider nicht: USB Pad und USB Controller im Nxp sind beides Devices. Was fehlt ist ein passender Host, z.b. PC. Danke für den Tip mit dem ICON i-Stage!Werde mir das Teil mal irgendwo ausleihen zum Ausprobieren. Ich habe ein NanoPad I mit 12 Pads, welche eine recht ordentliche Ansprache beim Drum tappen haben, aber leider nicht beleuchtet sind um verschiedene Modi (Drum tap, Sample teigiger, scene change etc.) anzuzeigen. Gruß Jo
  14. Hallo Thorsten Danke für die Beschaltungsvarianten der verschiedenen Keyboard Typen Ich sehe nur noch nicht ganz, warum bei den 76- & 88-Tasten Versionen 2 DIO Module gebraucht werden. Die T1..T8 Outputs werden für die rechte und linke Seite jeweils auf 1 HC165 Input gelegt, bilden also einen 16-bit Input Wert. Wenn man also nur eine Bk oder Mk Scanline aktiviert steht der entsprechende Tx Wert entweder im LSB oder MSB des 16 Bit Inputs. Aktiviert man aber 2 Bks oder MKs (jeweils 1 in der linken und 1 in der rechten Hälfte), so kann man den kompletten 16-bit Input auswerten und bekommt pro Scan Schritt gleichzeitig die Werte für die linke und rechte Hälfte. Vorteil: Nur 1 DIO notwendig. Scans für komplettes Keyboard werden fast um die Hälfte reduziert (je nach Keyboard Variante). Nachteil: die Verdrahtung vom Keyboard zum DIO ist nicht mehr so schön 1:1 wie bei der 61-Tasten Version, aber laut deinen Zeichnungen hat es bei der 76er und 88er Version sowieso gekreuzte Leitungen. SW etwas aufwändiger. Klingt noch etwas kompliziert, werde übers Wochenende mal eine Tabelle erstellen, welche das Ganze (hoffentlich) etwas mehr verdeutlicht, was ich meine. Gruss Jo
  15. Hallo Thorsten. Toller Print, den du "so aus dem Handgelenk" generiert hast. Vielleicht solltest du noch bei der Fatar Kompatibilität darauf hinweisen, dass dies nur für das 61 Keyboard gilt (s. http://www.doepfer.d...Y/Matrix_61.gif).Das 76 KB hat einen 16-pol & einen 20-pol. Micro-Match mit verdrehten BK, und MK Sammelschienen (s. http://www.doepfer.d...Y/Matrix_76.gif)Das 88 KB hat wiederum zwei 20-pol. Micro-Match (s. http://www.doepfer.d...Y/Matrix_88.gif) was bei allen 3 Keyboard Varianten vom Pinning auf dem Flachbankabel gleich ist, sind die T1 bis T8 zum Input Schieberegister HC165. Gruss Jo
  16. Hallo, dieses File müsste bei dir unter c:/mios32/trunk/drivers/LPC17xx/CMSIS/inc/ zu finden sein. Im Zweifelsfall nochmals ein SVN "update" auf deinem MIOS32 Verzeichnis durchführen. Gruß Jo
  17. Hi Thorsten I think I found a small bug in http://svnmios.midib...rc%2Fkeyboard.c in fct. void KEYBOARD_Periodic_1mS(void) { ::::::::::::::: ::::::::::::::: // check all 8 pins of the SR // should be: 16 ? int sr_pin; u8 mask = 0x01; // should be: u16 mask = 0x0001; for(sr_pin=0; sr_pin<16; ++sr_pin, mask <<= 1) if( changed & mask ) KEYBOARD_NotifyToggle(kb, row, sr_pin, (din_value[kb][row] & mask) ? 1 : 0); } } } Regards, Jo
  18. Hallo Thorsten Vielen Dank, dass du dich so in das Keyboard Projekt reinhängst !!! Das wäre super. Gruß, Jo
  19. Hallo fpele Den neuen Sensor meinte ich nicht, dieser ist als Ribbon controller konzipiert. Mir schwebte dieser Restposten vor:
  20. @fpele Die Splitzonen wären dann durch die 4 Zonen HW-seitig vorgegeben, was gerade bei einem Masterkeyboard mit Preset Verwaltung die Flexibilität doch sehr einschränken würde. Diese Leitgummistreifen hatte ich auch schon mal ins Auge gefasst. Ausser als Restposten bei Döpfer in reduzierten Längen habe ich sie aber noch nirgends gesehen. Wer liefert so etwas als Meterware, zu welchem Preis, bei welcher Mindestmenge? Für Links wäre ich sehr dankbar! Ich kenne Leitgummi nur aus meiner Zeit als Praktikant bei einem DC-Motoren-Hersteller. Das Zeug war bretthart. Oder als feinporigen Moosgummischaum, wobei mir die Elastizität ~ Widerstand über die Lebensdauer einer Tastatur doch sehr fragwürdig erscheint. Das schaffe ich auch nicht, aber das ist auch gar nicht der Grund für meinen Wunsch nach PolyAT. Hauptgrund bleibt der Wunsch nach frei wählbaren Splitzonen ggf. in unterschiedlichen Konfigurationen/Preset. Aus PolyAT läßt sich durch Mittelung der gedrückten Tasten innerhalb einer Zone der ChanAT für den MIDI ch. dieser Zone ermitteln, aber nicht umgekehrt. Viele (ältere) HW-Synthis kommen mit PolyAT sowieso nicht zurecht. Aber Soft(VST)-Synthis können durchaus damit umgehen, spez. nach der neuen VST Spec. V3.5 (Note Expression). Gute Idee, sollte aber zusätzlich einen frei zuweissbaren Controller (CC) haben, nicht reduziert auf nur Ch. AT. Weiterhin bräuchte dieses Mod-Wheel eine Rückholfeder auf die Anfangspositioon, sonst erlebt man beim Spielen böse Überraschungen, sollte der zugewiesene Synthi AT interpretieren, der Spieler aber nicht die Hand am (AT-)Wheel hat. Gruss, Jo
  21. Hallo Thorsten, Mario Ich bin´s schon wieder Zum Thema Key/Poly-Aftertouch: Die Ersten, die so was relativ klever realisiert haben, waren die Entwickler vom Rhodes Chroma Synth. in den frühen 80ern. Sie entwickelten dafür sog. FDRs (force dependent resistor). Eine spezielle Mimik aus gelayerten Folien mit Luftpolsten und mäanderformig geätzten Leitern. siehe unter: http://www.rhodeschr...=pressuresensor Ich habe mir das lange überlegt, ob sowas nicht zum Nachbau geeignet wäre ind bin dabei auf die FSRs von Interlink electronics gestoßen. http://www.interlink...tandard-400-FSR Leider sind sind die Dinger selbst bei 100er Stückzahlen für DIY PolyAT viel zu teuer, so um die 5 USD /Stk.& Taste. (s. http://www.trossenro...istor-FSR-.aspx) Wie es mit der mechanischen Abnutzung aussieht, who knows? Durch Zufall bin ich vor einigen Wochen auf folgenden Link gestoßen: http://sebion.wordpress.com/ Ein Physikstudent aus Bielefeld hat so ein billiges Thoman Piano mit Reflex Optokopplern (CNY 70 -,75 Euro/Stk.) versehen und jeweils 8 Stück (1 pro Taste) an einen ATmega controller gehängt. Von den Controllern hat er dann 11 Stück für 88 Tasten via I2C in Serie gehängt und an einen Master Controller vom selben Typ angeschlossen. Nur für PolyAT könnte man sich die Controller Mimik sparen, da ja nur die gedrückten Tasten interressieren, und für die update rate 2-5 ms/gedrückter Taste völlig ausreichen. Weiterhin sollte das Senden von AT daten erst nach einer Totzeit von 10ms beginnen, um den angehängten Synthi nicht mit Daten zuzumüllen. Vorteile opt. Reflex Sensor: mech. kontaktlos/verschleissfrei; rel. preiswert vgl. zum FSR. Nachteile opt.: die Bauhöhe unter der Tastatur muss um ca. 10-15 mm erhöht werden (wg. PCB + Bauteil; muss für jede Tastatur angepasst werden; evtl muss die Tastatur von unten mech. modifiziert werden (Feile & Tipex), um reproduzierbar gleichhohe reflektierende Flächen zu bekommen. Die vorgeschlagene Beschaltung der LEDs im Opt. Sensor sollte so modifiziert werden, dass nur jene LED auch angesteuert wird, wenn die zugehörige Taste auch gedrückt ist oder gescannt wird. Das sind nur so ein paar Ideen. Gruss, Jo
  22. Das ist tatsächlich möglich! Ein Physikstudent aus Bielefeld hat so ein billiges Thoman Piano mit Reflex Optokopplern versehen und jeweils 8 Stück (1 pro Taste) an einen ATmega controller gehängt. Von den Controllern hat er dann 11 Stück für 88 Tasten via I2C in Serie gehängt und an einen Master Controller vom selben Typ angeschlossen.:whistle: Der Master Controller bedient auch noch 8 Fader + LCD für die Anschlagsparameter ,die Pianopedale und die (MIDI-)Kommunikation zum PC. Guckst du unter: http://sebion.wordpress.com/ Gruss Jo
  23. Hi Thorsten, Aggreed to all your points :) Just had a rough look at the new project you mentioned above. Looks very promissing. Looking forward for your coded ideas.:) Kindly Regards, Jo PS: If you are in the Bodensee region, let me know via pm. Appart from cristal-clear water, we also have several sorts of good beer!. :wink:
  24. Hi Thorsten I admire your passion in bringing ideas to well structured code! Imho APP_SRIO_ServicePrepare() and APP_SRIO_ServiceFinish() can be accellerated: Skip MIOS32_DOUT_SRSet() of final contact row 2, 4, 6, 8, 10 for the Korg KB if din_value of the related early contact row 1, 3, 5, 7, 9 is 0xff (no early contact pressed) I observed this behavior on a Fatar keyboard some time ago, see: one small side note to your Readme.txt and code comments, I´m a little confused about the meaning of your word depressed. Does it mean released/untouched? Kindly Regards, Jo
  25. Thanks Thorsten for your immediate and detailed answers Best Regards, Jo
×
×
  • Create New...