Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. In comparison to Bitwig we've a different situation: while Bitwig is developed by a professional company with focus to satisfy as many users as possible (to earn as much money as possible ;-), MBSEQ is only a sparetime project, mainly developed by myself.

    Of course, MBSEQ is open source, and there is something like a API which could be enhanced or customized by users, but it requires some selfeducation about MIOS32 and the firmware architecture + C programming skills. E.g. somebody could adapt the "BLM_SCALAR_MASTER" driver, which transfers LED states and converts button actions, to another controller: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fblm_scalar_master%2F

    Or somebody could customize the next upper layer called "SEQ_BLM" which allows the external controller to access sequencer functions: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fcore%2Fseq_blm.c

    Concerning direct USB connection to the launchpad: unfortunately there are three reasons why this doesn't work with the launchpad: 

     

    Best Regards, Thorsten.

  2. Yes, this command should do the trick.

    It seems that there are variables which are not reset, this isn't intended - on the other hand I've currently no idea what I'm missing here.

    Would it be possible to create a minimal .NGC file which I could use to reproduce the issue at my side?

    Best Regards, Thorsten.

  3. In the past J8/9 RC1/RC2 was a common line at the core (MBHP_CORE_PIC, MBHP_CORE_STM32), but always routed as separate lines at DIN/DOUT PCBs.

    With MBHP_CORE_LPC17 and MBHP_CORE_STM32F4 I introduced separate RC1/RC2 lines at J8/9 core side for future enhancements.

    This feature isn't used by MIOS32 yet (it just sets both pins at once), but it could be used in future for whatever reason.

    Best Regards, Thorsten.

  4. Hi Matthias,

    I just tested the following at my end:

    • uploaded usb_midi_2x2_v1_010 application to a STM32F4 core
    • no error message noticed
    • disconnected USB cable to my computer, connected USB host adapter
    • STM32F4 powered via J2 (but I also tested power supply via STLink USB socket)
    • connected M-Audio Oxygen49 keyboard
    • reseted the core (pushing black button) to ensure that the keyboard will be found
    • -> MIDI data will be sent via MIDI OUT1.
    • The green status LED on the STM32F4DISCOVERY board will flash whenever the keyboard sends data

    Which error message did you get exactly?

    Best Regards, Thorsten.

  5. Am einfachsten waere es wohl, wenn Du eine bereits vorhandene Funktion, die Du nicht benoetigst, kannibalisierst.

    Bspw. den "BUTTON_MIXER".
    Die Pin-Zuweisung wuerdest Du in Deinem MBSEQ_HW.V4 File eintragen (suche dort nach BUTTON_MIXER)
    Diese wird dann die SEQ_UI_Button_Mixer() Funktion in seq_ui.c aufrufen... ab dort kannst Du dann weitermachen ;-)

    Alternativ eine neue Button-Funktion einbauen, doch das waere umstaendlicher - Du koenntest bspw. nach einem geeigneten Stichwort greppen, so weisst Du, welche Files zu aendern sind.

    Hier ein Beispiel: 

    MacMini2:midibox_seq_v4 TK$ grep -i track_transpose core/*
    core/seq_file_hw.c:	  } else if( strcasecmp(parameter, "TRANSPOSE") == 0 || strcasecmp(parameter, "TRACK_TRANSPOSE") == 0 ) {
    core/seq_file_hw.c:	    seq_hwcfg_button.track_transpose = din_value;
    core/seq_file_hw.c:	  } else if( strcasecmp(parameter, "TRANSPOSE") == 0 || strcasecmp(parameter, "TRACK_TRANSPOSE") == 0 ) {
    core/seq_file_hw.c:	    seq_hwcfg_led.track_transpose = dout_value;
    core/seq_hwcfg.c:  .track_transpose = ((( 0   -1)<<3)+    0),
    core/seq_hwcfg.c:  .track_transpose = ((( 0   -1)<<3)+    0),
    core/seq_hwcfg.c:  .track_transpose = ((( 0   -1)<<3)+    0),
    core/seq_hwcfg.h:  u8 track_transpose;
    core/seq_hwcfg.h:  u8 track_transpose;
    core/seq_ui.c:  if( pin == seq_hwcfg_button.track_transpose )
    core/seq_ui.c:  SEQ_LED_PinSet(seq_hwcfg_led.track_transpose, ui_page == SEQ_UI_PAGE_TRKTRAN);

    In SEQ_UI_Button_FootSwitch siehst Du, wie man einen Doppelklick realisiert.

    Best Regards, Thorsten.

  6. Ich habe eine Vermutung: J10B wird ja beim STM32F4 core fuer die optionalen DIN Clock Outputs verwendet, die stehen nun natuerlich im Konflikt mit den LCD Pins (die ja urspruenglich nicht in der Firmware vorgesehen waren).

    Ich habe nun seq_cv, seq_hwcfg und seq_file_hw so geaendert, dass die Pins nicht initialisiert werden sollten, wenn im MBSEQ_HW.V4 File "J5_ENABLED" auf 0 gesetzt wurde.

    Probiere es mal aus: hole Dir die aktuellen Sourcen aus dem Repository, aendere den Wert fuer J5_ENABLED in Deinem MBSEQ_HW.V4 file auf der SD Karte, und tippe dann "reset" im MIOS Terminal.

    Danach sollten die LCDs eigentlich funktionieren. Falls nicht, muesste man ueberpruefen, ob die Pins noch irgendwo anders gesetzt, und nicht ueber die neue Variable "seq_hwcfg_j5_enabled" gegated werden.

    Gruss, Thorsten.

  7. Die Breakpoints werden bei dem optimierten Code nicht immer zuverlaessig funktionieren.

    Dahinter steht ja:

      // check if if display already has been disabled
      if( !(display_available & (1ULL << mios32_lcd_device)) )
        return -1;
    

    welchen Wert hat display_available? Ich wuerde 15 (hexadezimal 0xf) erwarten.

    Evtl. macht es Sinn, den Breakpoint in SEQ_LCD_Update() zu setzen, bspw. an der Stelle wo MIOS32_LCD_DeviceSet aufgerufen wird - und ab da mal durchsteppen.

    Gruss, Thorsten.

  8. Neither the demonstrated LED behaviour, nor the received MIDI messages make sense, and I'm surprised that anything is working at your side...

    How exactly did you connect the cores via MIDI?
    E.g. are you using optocouplers?

    And are you able to doublecheck the behaviour with a PIC based mini core, just to get more information about the root cause?

    Best Regards, Thorsten.

  9. Hallo Gidien,

    MIOS32 wird standardmaessig nur die beiden ersten LCDs initialisieren.

    Du muesstest also in SEQ_LCD_Init() noch folgendes einbauen (habe das gerade dementsprechend im SVN repository geaendert):

    s32 SEQ_LCD_Init(u32 mode)
    {
      u8 dev;
    
      // first two LCDs already initialized in main.c
      // for the case that more than two LCDs have been configured:
      for(dev=2; dev<LCD_NUM_DEVICES; ++dev) {
        MIOS32_LCD_DeviceSet(dev);
        MIOS32_LCD_Init(0);
      }
    
      // switch back to first LCD
      MIOS32_LCD_DeviceSet(0);
    
      return 0; // no error
    }
    


     

    Quote

    Die beiden zusätzlichen E-Pins sind an J10B D0 und D1 angeschlossen. Wenn ich die app_lcd.c richtig gelesen habe, sind die Pins D0 - D7 auf J10B für weitere E-Pins vorgesehen.

    Sind die Anschlüsse dort richtig ???

    Ja, das sind die richtigen Pins

    Gruss, Thorsten.

  10. I've no explanation for this issue, and I'm not able to reproduce it.

    What happens if you add

    BLM_SCALAR_MASTER_ForceDisplayUpdate();

    whenever one of the horizontal extra buttons is pressed, after the 16x16 grid LEDs have been set?
    Are the LEDs set like expected thereafter?

    I've also no explanation why faders should trigger button events.
    Do they sent CC events?
    You can doublecheck this by displaying incoming events in APP_MIDI_NotifyPackage like shown in this example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F003_debug_messages%2Fapp.c

    Best Regards, Thorsten.

  11. Hi Lamster,

    don't worry, in the past (as a teenager) I programmed PETs as well and know this situation. Let's say it this way: space invaders is already part of the firmware, you only have to configure it (should the spaceships attack vertically or diaconal? ;-)
    Nobody will complain if you've questions how to configure it correctly, as long as you raise up the right questions which allow us at the "remote end" to understand the situation - and this requires sometimes "literature research".

    So, here are two webpages as a starting point:

    This page explains how to setup a STM32F4 microcontroller, which will be the brain of your MIDIbox NG: http://www.ucapps.de/mbhp_core_stm32f4.html

    Even w/o the MBHP_CORE_STM32F4 PCB, you will already be able to flash the firmware (either via MIDI bootloader, or by directly flashing the .hex file - sooner or later you want to access via MIDI anyhow!). But the PCB + some additional modules (such as MBHP_DIN, MBHP_DOUT, MBHP_AINSER64) will allow access to the IO pins. The corresponding documentation can be found at ucapps.de as well; PCBs can be ordered at http://midibox-shop.com

    Once the MIDIbox NG firmware has been programmed, the "First Steps" page help you to do get familiar with the MBNG "programming language": http://www.ucapps.de/midibox_ng_manual_fs.html

    Best Regards, Thorsten.

  12. The optimization takes place in BLM_SCALAR_MASTER, so that you can now work at a higher level where execution speed doesn't matter anymore.

    MBSEQ is a different story - the SEQ_BLM code is a critical element since it is running in parallel to many other UI processes, therefore I had to spent more effort into the optimization (e.g. I had to access variables directly - which is dangerous for programmer newbies because of potential hard faults!)

    Best Regards, Thorsten.

×
×
  • Create New...