Jump to content

TK.

Administrators
  • Posts

    15,247
  • Joined

Posts posted by TK.

  1. Ah! Sorry, I picked up the wrong example.

     

    This is a better one: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Ftpd.ngc

    (it tests the TPD, which consists of two 8x8 duo-LED matrices, driven by DOUT_MATRIX n=2 and n=3)

     

    As you can see, each DOUT_MATRIX has 16 EVENT_LED_MATRIX entries, regardless of the number of rows.

    In order to ensure individual access, I would propose to define 4 DOUT_MATRIX items:

    /edit: corrected DOUT_MATRIX assignments.

    DOUT_MATRIX n=1   rows=4   sr_dout_sel1=4  sr_dout_r1=3  
    DOUT_MATRIX n=2   rows=4   sr_dout_sel1=4  sr_dout_r1=5
    DOUT_MATRIX n=3   rows=4   sr_dout_sel1=7  sr_dout_r1=6  
    DOUT_MATRIX n=4   rows=4   sr_dout_sel1=7  sr_dout_r1=8  
    

    you should be able to control the LED bars with:

    EVENT_LED_MATRIX id= 1 type=CC  chn= 1 cc= 16  led_matrix_pattern=1
    EVENT_LED_MATRIX id= 2 type=CC  chn= 1 cc= 17  led_matrix_pattern=1
    EVENT_LED_MATRIX id= 3 type=CC  chn= 1 cc= 18  led_matrix_pattern=1
    EVENT_LED_MATRIX id= 4 type=CC  chn= 1 cc= 19  led_matrix_pattern=1
    
    EVENT_LED_MATRIX id=17 type=CC  chn= 1 cc= 20  led_matrix_pattern=1
    EVENT_LED_MATRIX id=18 type=CC  chn= 1 cc= 21  led_matrix_pattern=1
    EVENT_LED_MATRIX id=19 type=CC  chn= 1 cc= 22  led_matrix_pattern=1
    EVENT_LED_MATRIX id=20 type=CC  chn= 1 cc= 23  led_matrix_pattern=1
    
    EVENT_LED_MATRIX id=33 type=CC  chn= 1 cc= 24  led_matrix_pattern=1
    EVENT_LED_MATRIX id=34 type=CC  chn= 1 cc= 25  led_matrix_pattern=1
    EVENT_LED_MATRIX id=35 type=CC  chn= 1 cc= 26  led_matrix_pattern=1
    EVENT_LED_MATRIX id=36 type=CC  chn= 1 cc= 27  led_matrix_pattern=1
    
    EVENT_LED_MATRIX id=49 type=CC  chn= 1 cc= 28  led_matrix_pattern=1
    EVENT_LED_MATRIX id=50 type=CC  chn= 1 cc= 29  led_matrix_pattern=1
    EVENT_LED_MATRIX id=51 type=CC  chn= 1 cc= 30  led_matrix_pattern=1
    EVENT_LED_MATRIX id=52 type=CC  chn= 1 cc= 31  led_matrix_pattern=1

     

    Best Regards, Thorsten.

  2. Thanks for the files!

     

    This was a simple bug: the MIDI clock was output at 384 ppqn (inherited from the original MIDIbox SEQ V4 code), but a .mid file can have it's own ppqn rate which was ignored.

     

    It's fixed now, please try this version: http://www.ucapps.de/mios32/midio128_v3_017_pre1.zip

     

    Please note that the REC1.MID file won't output a proper clock whenever the song is looped, because re-loading from SD Card takes some time at which no MIDI clock event is sent.

     

    Best Regards, Thorsten.

  3. Could it be, that your core is assigned to a different device ID?

    This would explain, why it won't be found via Query.

    It's also a plausible reason, because the storage file of the device ID number has been changed between MIOS Studio 2.2 and later versions.

     

    So: try different IDs, push the Query button after each change to check if the core will be found.

     

    Best Regards, Thorsten.

  4. Maybe the bootloader update left some artifacts in the MacOS setup.

     

    What happens if you:

    • remove the J27 jumper (don't use bootloader mode, so that the MIDIbox NG application with it's 4 USB-MIDI ports is active)
    • start the Audio-MIDI-Setup of MacOS (e.g. search for "audio-midi" with Spotlight)
    • disconnect the core module from USB
    • delete the interface in the Audio-MIDI-Setup
    • connect the core module to USB again

    Thereafter re-start MIOS Studio and select the first MIDI IN/OUT of your MIDIbox NG

    Is the Query working thereafter?

     

    Best Regards, Thorsten.

  5. Hi Robin,

     

    there is no special configuration required in the application, but you have to configure the dedicated DOG CLCD mode in the bootloader

    set lcd_type CLCD_DOG
    If this doesn't help, then try out a different cursor map.

    Because the cursor position handling is different from common CLCDs.

     

    E.g. what happens with:

          u8 cursor_map[] = {0x00, 0x40, 0x14, 0x54}; // offset line 0/1/2/3
          MIOS32_LCD_CursorMapSet(cursor_map);
    
    And what happens with:
          u8 cursor_map[] = {0x00, 0x10, 0x20, 0x30}; // offset line 0/1/2/3
          MIOS32_LCD_CursorMapSet(cursor_map);
    
     

    Best Regards, Thorsten.

  6. Finally I got it working and ordered the panels :)

     

    Solution:

    - I'm using Inkscape under Linux (running in a virtual box)

    - Ilmentator sent me a .svg file

    - this file has to be modified with a text editor, otherwise Inkscape can't load it: remove xmlns="&ns_svg;"

    - do the required modifications (frame around the elements & create a bottom panel)

    - upload the new .svg to Formulor

     

    Best Regards, Thorsten.

  7. Hi Klaus,

     

    thanks for the offer, but I fear that this won't bring new insights.

    There seems to be something special if connections are directly routed on a PCB (e.g. w/o J15 & J28 sockets between OLEDs and LPCXPRESSO module).

    It's maybe possible to compensated this via software, but I've to analyze this on my bench.

     

    Best Regards, Thorsten.

  8. Ok, understood the problem: the .NGC file parser was too restrictive - I released a mbng_file_c.c change in the repository which allows swapped pins, and which should raise an error message on unsupported pin combinations.

    Please help to test this (critical) change - we've to avoid that valid pin combinations are refused by the parser due to a potential programming error!

     

    Best Regards, Thorsten.

  9. I could easily add a key combination which allows to do this.

    The copy function would have to store the layer was active during the capturing.

    The paste function would have to be combined with another key to transfer the previously selected layer only - maybe SELECT+PASTE?

     

    Best Regards, Thorsten.

  10. Hi,

     

    status from my side: I created a board with 4 additional OLEDs today, and connected it in parallel to my first board (CS lines are uncritical, therefore this doesn't matter)

     

    I still get very stable display output, even when I'm using an extra-long cable to J15:

    oled9.jpg

    Conclusions so far:

    - SCLK and SDA (D0 and D1) still uncriticial when 9 OLEDs are connected in parallel

    - I tested this with a "new gcc" build

    - the "new gcc" build leads to the same results on two different hardware implementations (KUI & Novski)

    I've still no clue what could cause such an issue :-/

    How can I get direct access to the hardware?

    Novski: you are located in Switzerland, I guess it would be too expensive to ship your PCB to germany.

    KUI: where are you located?

    Best Regards, Thorsten.

  11. Inkscape doesn't work correctly at my side, the GUI elements are not correctly displayed (I'm using the latest XQuartz version)

     

    In Libre Office, I've ensured that the correct RGB values are used.

     

    Ilmenator, could you please send me the exact file you've used during your Formulor order? I would like to doublecheck, if I'm able to convert this one with Libre Office

     

    Best Regards, Thorsten.

×
×
  • Create New...