Jump to content

nlate

Programmer
  • Posts

    68
  • Joined

  • Last visited

Posts posted by nlate

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

     


     

     

     

  2. 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

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

    post-6136-0-20946500-1358695948_thumb.jp

    post-6136-0-32845000-1358696044_thumb.jp

    post-6136-0-37766700-1358696115_thumb.jp

    post-6136-0-65689500-1358696185_thumb.jp

    post-6136-0-04840200-1358696233_thumb.jp

    post-6136-0-99711700-1358696277_thumb.jp

    post-6136-0-39859800-1358696324_thumb.jp

    MBKBtimings.zip

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

  5. 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

    post-6136-0-13118000-1351451413_thumb.jp

    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

    post-6136-0-02787900-1351451524_thumb.jp

    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

    post-6136-0-29335400-1351451564_thumb.jp

    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

  6. Dear Thorsten,

    Thank you very much for the input! :)

    I updated the schematic: http://www.ucapps.de...connections.pdf

    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

  7. Hallo Brathering

    Wenn die PADs nach dem "Piezoprinzip" arbeiten, so kannst diese an ein AIN_module anschließen, dann bleibt auch die Anschlagdynamik erhalten.

    -> Druck löst Steuerspannung in je nach Druck variabler Höhe zwischen min - max aus, diese lässt sich interpretieren und z.B als velocity-Signal nutzen.

    Andere Bauprinzipien, sowie der Weg via AINSERT, laufen wahrscheinlich auch, da hab ich mich aber bisher nicht mit beschäftigt um das definitiv bestätigen zu können.

    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

  8. Wieso sollte des nicht gehen, ob ich zwei getrennte USB-Geräte extern über HUB mit dem Rechner verbinde, oder den Hub zusammen mit den Geräten in ein Gehäuse integriere ist doch Jacke wie Hose!

    Technisch absolut identisch, spart halt nur (optisch) das eine Kabel.

    Evn. liegts ja daran das ich nicht weiß, was NXP bedeutet(!?)

    Hallo Brathering

    Vielleicht habe ich das dann falsch verstanden:

    In dein Keyboard bauste dann einen USB-Hub rein, da kannste das dann direkt anschließen.

    ...

    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

  9. 1339233194' post=148712]In dein Keyboard bauste dann einen USB-Hub rein, da kannste das dann direkt anschließen. Oder klemmst es vom internen Controller ab und verdrahtest es dann auf die Midibox (dort wohl an die AINSER64). Dann haste alles nur auf dem Midibox-Controller und bist flexibler, da die Konfiguration dann über MIOS läuft.

    Gruß

    Frank

    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

  10. Hallo Thorsten

    Danke für die Beschaltungsvarianten der verschiedenen Keyboard Typen

    Wie bspw. die Verdrahtung von den verschiedenen Fatar-Keyboards. Fuer die 76- und 88-Tasten-Version werden zwei DIO_MATRIX Module notwendig sein (oder ein DINX4 und ein DOUTX4).

    Die nicht genutzten Ein- und Ausgaenge stehen fuer andere Zwecke zur Verfuegung, bspw. fuer zusaetzliche Tasten, aber auch LEDs

    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

  11. Hallo Thorsten.

    Toller Print, den du "so aus dem Handgelenk" generiert hast.

    Features:

    • ...
    • die Pinbelegung von J3 und J4 ist 1:1 kompatibel zum Fatar Keyboard!
    • das Board ist auch fuer andere Anwendungsfaelle geeignet, man kann bspw. auch LEDs anschliessen, entweder in Matrix oder Direkt-Verschaltung (die Widerstaende muessen dann extern verloetet werden

    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

  12. Hallo,

    C:\mios32\trunk\midio128_v3>make

    rm -f project.hex

    Creating object file for app.c

    In file included from src/app.c:18:0:

    c:/mios32/trunk/include/mios32/mios32.h:33:22: fatal error: LPC17xx.h: No such file or directory

    compilation terminated.

    make: *** [project_build/src/app.o] Error 1

    Ich finde die LPC17xx.h auch nicht auf der Festplatte.

    Habe ich da irgend ein teil vergessen herunter zuladen ?

    Zu welchen Verzeichnis gehört die datei ?

    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

  13. Hi Thorsten

    Meanwhile I started with MIDIbox KB:

    http://svnmios.midib...idibox_kb_v1%2F

    which can service multiple keyboards of multiple types - here such an optimization would lead to unnecessary complexity, especially once the remaining DOUTs should be used for driving a LED matrix as well.

    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

  14. Hallo Thorsten

    Vielen Dank, dass du dich so in das Keyboard Projekt reinhängst !!!

    Zum Thema Encoder habe ich mir auch schon etwas ueberlegt: die zusaetzlichen Shift Register in der DIN Kette wuerden ja eigentlich die Latenz der Keyboard-Abtastung erhoehen, doch ich koennte den Algorithmus auch so erweitern, dass nur einmal pro Millisekunde die komplette DIN-Kette durchgeschoben wird, und ansonsten maximal 2 oder 4 DIN Shift Register, je nach Anzahl der Tastaturen.

    Da dies in wenigen Mikrosekunden geschieht, sollte die Velocity-Berechnung davon nicht beeintraechtigt werden.

    Das wäre super.

    Gruß, Jo

  15. Hallo fpele

    Der neue Drucksensor von Doepfer ist wohl eher ungeeignet... Der Bereich scheint zwar ganz brauchbar zu sein, aber dann doch teuer, wenn für jede Taste ein Sensor gebraucht wird.

    Den neuen Sensor meinte ich nicht, dieser ist als Ribbon controller konzipiert.

    Mir schwebte dieser Restposten vor:

    Drucksensor/Leitgummistreifen ca. 245 x 13 x 1 mm (Ersatzteil für A-198 / MIDI-Ribbon-Controller, alte Version, es werden jeweils 3 benötigt) /

    Details siehe Zubehör und Ersatzteile Auslauftyp, Verkauf solange Vorrat reicht

    Gruß, Jo

  16. @fpele

    Und dann spielt man mit mehreren Tasten gleichzeitig verschiedene Aftertouch-Werte für die Instrumentierungen? Gut, wenn gesplittet wird, ist man frei bei der Wahl... Reicht da nicht aus, z.B. 4 Zonen (bei 61 Tasten) vorzusehen und dann diese Zonen mit einem Drucksensor auszustatten?

    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.

    Den Drucksensor gibt es als 1 mm starken "Gummistreifen", der Widerstandswert wird dann über ein AIN-Eingang ausgewertet.

    So würde ich mir die Lösung vorstellen.

    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.

    Ich bringe es jedenfalls nicht fertig, mit allen Fingern auch nur annähernd einigermassen gleiche AT-Werte zu produzieren... Mit den beiden kleinen Fingern keine Chance.

    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).

    Deswegen bin ich schon darauf gekommen, mir für den AT ein extra Mod-Wheels vorzusehen. Habe also dann 3 Stück: Pitch, Mod-Wheel, AT-Wheel.

    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

  17. Hallo Thorsten, Mario

    Ich bin´s schon wieder

    Weisst Du eigentlich, ob Aftertouch eine spezielle Mechanik benoetigt?

    /edit: habe mich mittlerweile informiert, es ist ein spezieller Sensor im Keyboard integriert, der liese sich ueber einen freien ADC Kanal auswerten, wenn eine Taste gedrueckt ist.

    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

  18. Ich meine etwas in Richtung PNOScan.

    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

  19. 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

  20. Hi Thorsten,

    I looked into the code at app.c of tutorial #29 and have some (may be silly) questions:

    1. Why don´t you use a debounce fct. ?
      Is this not necessary, because today´s keyboards (Fatar etc.) use bubble contacts.
    2. If I want to use 16bit (u16) array variables, to save valuable RAM space, does this cost more exec cycles on an ARM core?
      (I am an injured Intel x86 guy :pirate:)
    3. What about timestamp wraparound?
      (after 15 days running the tutorial)

    Thanks in advance for responding.

    Kindly Regards

    Jo

×
×
  • Create New...