Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. Thorsten, würdest du das grundsätzlich empfehlen um möglichen Fehlerquellen gleich vorzubeugen oder nur unter gewissen Umständen? Falls ersteres wäre es toll, wenn man das in den anderen Schaltplänen auch sehen würde  :smile:

     

    Du solltest vielleicht erwaehnen, auf welchen Schaltplan Du Dich beziehst (jedenfalls nicht auf den neuen Schaltplan)

     

    Man benoetigt die RCs, wenn die LEDs anfangen wild zu flackern. Das wird bei einer sauberen Verdrahtung mit den neueren MBHP_* PCBs nicht passieren.

    Bei den alten PCB Layouts war das noch ein Problem, weil die Module bspw. nicht ueber Flachbandkabel verbunden wurden. Auch wer das Frontpanel komplett auf Lochraster aufbaut, und dabei auch noch die DIN/DOUT Shiftregister wild vermischt, laeuft Gefahr, dass die SR Signale nicht mehr sauber uebertragen werden.

    Siehe auch 

     

    Das Problem ist also eigentlich mit den neuen PCBs von SmashTV seit einigen Jahren geloest, ich lasse jedoch den Hinweis im MBSEQ Schaltplan, und werde ihn in keine anderen Schaltplaene uebertragen, weil er in den meisten Faellen nicht relevant ist.

     

    Gruss, Thorsten.

  2.  

    Ja, an der Standard-Belegung hat sich in den letzten 10 Jahren nichts geaendert (ansonsten wuerden mir einige User aufs Dach steigen! ;-)

     

    Ich habe das HW Manual (-> http://www.ucapps.de/midibox_seq_manual_hw.html) jedoch gerade um ein neues Kapitel ueber das "Reduced DIN/DOUT" Kapitel erweitert, in dem die spezielle Verdrahtung von Wilba's Frontpanel PCB erklaert wird.

    Siehe auch http://www.ucapps.de/midibox_seq/mbseq_v4_dio_wilba_layout.pdf

     

    Hierfuer wuerde man also nur ein MBHP_DIO_MATRIX und ein MBHP_DINX4 (und kein MBHP_DOUTX4) Modul benoetigen.

     

     

    Wird der dritte DIN R5 wie hier der zweite an den ersten "in Reihe" angeschlossen?

     

    wenn man es benoetigt: ja

     

     

    • Ich möchte 16 Taster einbauen, um im Pattern-Modus die einzelnen Spuren schneller selektieren zu können.

      (Statt Track Group + Track)

     

    Es gibt nur 4 Pattern - fuer jede Gruppe (bestehend aus 4 Tracks) eins.

    Diese kann man auf der PATTERN Seite sehr schnell mit den GP Buttons anwaehlen, die Gruppe waehlt man mit den Group-Tastern aus

     

     

    • Wenn das geht, kann ich diese 16 Taster auch zum Muten benutzen?

      (Im Patte

      rn-Modus "Mute" + Taste mutet, nach Loslassen der Mute-Taste sofort wieder im Pattern-Modus)

     

    Die 16 Buttons sind ja nicht zum Pattern-Switching geeignet.

    Doch Du kannst sie zum Muten verwenden.

    Dazu legst Du sie auf die Bookmark-Funktion (BUTTON_DIRECT_BOOKMARK1 .. BUTTON_DIRECT_BOOKMARK16), und schreibst in das Bookmark-File, welcher Track ueber den jeweiligen Button gemuted werden soll.

     

    (Der Begriff "Bookmark" koennte hier etwas verwirrend sein, doch dahinter steckt eine maechtige Funktion, mit der man noch viel mehr machen kann also nur Tracks zu muten ;-)

     

    Gruss, Thorsten.

  3. Hi Tim,

     

    the firmware doesn't allow to enter notes exactly the way you want.

    You could play the notes in the Live page with the 16 GP buttons (they can be optionally forced to the selected scale) - but I know that this is no perfect replacement for your request - but it's currently the only possibility.

     

    Best Regards, Thorsten.

  4. Did you ever connect the LCD wrongly, e.g. with some cables swapped?

    This could damage the LCD, with the result that it can't be initialized. Possible effects: sometimes you will only see a black bar at the upper line, or you won't see any pixel at all.

     

    If you are sure that the LCD was never connected the wrong way, then it makes sense to doublecheck the connections between microcontroller, the 74HC595 SR and the LCD by comparing the signals at the source/destination with the two probes of your scope.

     

    If this still doesn't help, then I can only recommend to try another LCD

    (I'm not writing a different LCD type, Displaytech 162A works fine at my side)

     

    Best Regards, Thorsten.

  5. I'm lost, please help me!

     

    I'm unsure if we are speaking about the same behaviour, resp. if you've misinterpreted a change in the firmware and therefore come to this conclusion, or if we are talking about an actual issue (which is unknown to me).

     

    I changed the behaviour of the status LED with V3.019 - if you've used an older version before, the LED was dimmed (not so bright like with newer versions), and not fading/cycling.

     

    Best Regards, Thorsten.

  6. 1 - Is the setup for buttons correct with differents ports routing ?

     

    yes, it should work this way

     

     

    2 - What's the setup for the ledrings (to assignate the rings for each 24 channels) ?

     

    you've to define the  "EVENT_LED_MATRIX   id= 1  type=CC  chn= 1 cc=0x30  led_matrix_pattern=LcAuto" events three times, each one has to listen to another USB port.

     

     

    3 - For the meters could I assign  lc_meter_port=USB1 then USB2 and USB3 ?

     

    Yes, you need three DOUT_MATRIX components, and each one has to listen to another USB port.

     

     

    4 - Why my setup returns all the time at default when I reboot ?

     

    It works like intended.

     

    Rename your file to "DEFAULT.NGC" so that it will be loaded after startup

     

    Best Regards, Thorsten.

  7. Thorsten Könntest du mir bitte noch sagen ob es möglich ist die eigentlich für midi out gedachten pins MI3 und MI4 des J11E auch für Midi out zu nutzen ?

     

    Nein, das geht leider nicht, der STM32F4 ist leider nicht so flexibel im IO Multiplexing.

     

     

    Die App muss aber Quad IIC explizit unterstützen, oder? Mit der klassischen NG-App wird das doch nix, oder fehlen mir hier auch Infos? Auf der ucapps - Seite gibt es leider keinen Eintrag zu Quad IIC.

     

    koennte ich in die MBNG einbauen wenn es wirklich jemand benoetigt.

     

    Gruss, Thorsten.

  8. Hi Chris,

     

    it won't be possible to load a .NGC file without switching to another session, otherwise this could lead to inconsistencies (e.g. while storing/restoring snapshots, when labels are used, etc...)

     

    However, it's possible to switch to another setup.

    Please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre2.zip

     

    There is a new .NGR command called "LOAD"

    e.g. if you want to switch to XXX.NGC file, write:

     

    if ^section == 1
      load xxx
    endif
    

    and trigger this section from an event

     

    Best Regards, Thorsten.

  9. Hi Alex,

     

    I think that MIDIbox NG is the best choice in your case, no need to write a special firmware.

     

    Presets could be written into .NGR scripts, see also http://www.ucapps.de/midibox_ng_manual_ngr.html

    The script is directly executed from SD Card, there are commands to send any MIDI messages (including SysEx strings), so that there are actually no limitations.

     

    MBNG also supports graphical displays, see http://www.ucapps.de/midibox_ng_manual_lcd.html

    ST7920 GLCDs are not supported. If you don't want to write your own driver, please select a GLCD which is already supported by MIOS32.

     

    Best Regards, Thorsten.

  10. Hi,

     

    this behaviour indicates a bad MIDI interface (as you've already noticed).

    SysEx strings sent by the PIC are correctly received, but the PIC doesn't receive well shaped MIDI messages.

    This could also be related to a problem with the MIDI cable.

     

    Is TEST MIDI2 passing at your side?

     

    However, the Neusonik interface is really worth the money.

     

    Best Regards, Thorsten.

  11. Hi Sacha,

     

    two observations: does the lower waveform of the first picture really show the OE# line (Pin 13 of the 74HC595, resp. STM32F4 pin RC11, resp. J15:RW)?

     

    The OE# state should never change while new data is shifted into the 74HC595.

    If this is really J15:RW, then the problem is related to a connection error.

     

     

    Please also check the signal slope, it should be ca. 100 nS

    If a value transitions at the OE line takes more time (> 500 nS), then you are using the wrong pull-up resistors at R33, they should be 1k

     

    Best Regards, Thorsten.

  12. I think/hope that I found the problem! :smile:

     

    You've used "SRIO num_sr=16" after the matrix configuration, and this caused an inconsistency in the selection line pattern configuration, because it has been prepared for num_sr=32 before the SR number has been changed.

     

    Could you please try this version:

    http://www.ucapps.de/mios32/midibox_ng_v1_033_pre1.zip

     

    It doesn't fix the WARNING and ERROR messages.

     

    - some "#" (comments) are added at the end of the command line; this is currently not supported (but could be supported in future) - the appr. ERROR can be ignored

    - WARNING resolution=7bit: valid, because the resolution parameter is only supported for the AINSER device configuration command, not for EVENT_AINSER event commands

     

    Best Regards, Thorsten.

  13. Hi Bartosz,

     

    (I will look into your .ngc file later if really required).

     

    But to your questions: yes, the cable length does matter.

    You already noticed with an earlier firmware version some unstable scan values.

    Which means that the construct was already in a critical range - each change in the firmware can change the situation.

    E.g. slightly more activity in the firmware can cause a higher power consumption and if your core module is powered from a weak PSU (or a weak USB based supply), the situation can get worse.

     

    For further debugging it makes sense to check:

    - if it gets better with a different PSU. Resp. if your core module is powered via USB, please use a USB hub with external PSU

    - if v1.032 is working properly with less modules connected

     

    > Question2: what maximum length of cables between modules would you recommend?

     

    as short as possible (until it gets unstable ;-)

     

    However, there are measures to compensate long cables

     

    a) starlike SRIO wiring: after the two DIO_MATRIX modules, use a Y cable to connect two DINX4 and two DOUTX4 in a chain. Don't mix DIN with DOUT in the chain

    b) termination of the last SRIO modules in the chain with a 100 Ohm resistor + optionally 100 pF cap (not important if not available) between SC+Ground and RC+Ground. See also http://www.ucapps.de/midibox_seq/mbseq_v3_din.pdf and http://www.ucapps.de/midibox_seq/mbseq_v3_dout.pdf

    c) the usage of line drivers (brand new): http://www.ucapps.de/mbhp_line_driver.html

     

    However, before you start to try these measures, please feedback on the power supply topic before deciding the next steps.

     

    Currently I can't 100% ensure that the latest firmware changes were uncritical under all conditions, but under the assumption that the PSU and cable length topic isn't clarified yet, I think it's better to discuss this first before proceeding with the time consuming SW debugging round (where I will need your help as well, it will cost ca. 2..3 iterations to identify the root cause at your side)

     

    Best Regards, Thorsten.

×
×
  • Create New...