Jump to content

TK.

Administrators
  • Posts

    15,199
  • Joined

Posts posted by TK.

  1. Thanks for the input! I added a note to the schematic, that the pinning is not 1:1 compatible.

     

    MIDI OUTs: very strange!

     

    Following configuration allows you to doublecheck, if the MIDI OUT port is working regardless of the keyboard configuration:

    just enter following command into the MIOS terminal:

    set router 1 USB1 all OUT1 all

    thereafter play some notes on the virtual keyboard of MIOS Studio.

    They should be forwarded to the OUT1 port.

     

    If not, you know that the problem is related to the hardware.

    Check the MIDI circuitry on the MBHP_CORE_LPC17 module, and also check your MIDI cable (maybe it's defective?)

     

    Best Regards, Thorsten.

  2. Thanks for the video!

    It proves, that the problem is related to the SCLK line (and I had this assumption some weeks ago, but didn't follow this further).

    Meanwhile I assume that it's not related to CS lines (therefore also the usage of the serial output of IC2 would be the wrong direction).

     

    E.g. at 0:55 you can see a typical effect if an invalid command is shifted into the display. The display outpuz get's scrambled, but we can see that graphics are still changing - so, data transfers are still working correctly.

    Sometimes the display is scrolled down - again due to an invalid (received) command.

    If a display is turned off, then this could be caused by a wrong command as well.

    At 1:01 display 4 and 6 are working w/o re-initialisation, which means that previously they probably haven't received the data.

     

     

    I did some experiments at my side to provoke similar effects, and had success: by connecting a 100 Ohm resistor between 3.3V and SCLK (D0), the display content of some OLEDs (but not all OLEDs) get's corrupted like in the video.

    The interesting point: if I connect the resistor to D0 of display #1, content of #1 and #2 are still ok, and #3 and #4 get corrupted (currently I can only test this with 4 OLEDs) - again, similar to your video where different OLEDs show different behaviour.

     

    The effect doesn't happen with a 220 Ohm (or higher) resistor.

    But I guess, that I would see an effect if I would use more OLEDs.

     

     

    So, what does it mean: we've a 1k pull-up at E1 (outputs the SCLK), which results into a weak load. It could be, that the load get's relevant than more displays are connected. My experiment showed, that such a load can cause corrupted display contents at various (but not all) displays.

     

     

    Next experiments required at your side:

    1) of course, it would be nice if you could desolder the R33 resistor network (it isn't required for the SSD1306 setup anyhow), but it will be difficult...

     

    2) therefore, before doing this, please try out mios32_test_app_lcd_ssd1306_LPC1769_20131229_sda_at_rw.hex under following conditions:

    - disconnect the SCLK line of display #9..16 - are display #1..#8 working properly now?

    - connect SCLK line of display #9..16 with J15B:E2 (the alternative SCLK output) - are all displays working now?

     

    Please note, that you've to power-off the core for at least 5 seconds between each experiment to ensure, that the OLEDs are reseted properly.

    Otherwise they could still have a wrong configuration which leads to invalid output.

     

    Best Regards, Thorsten.

  3. Here the next try: http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769_20131229.zip

     

    This package contains two .hex variants: one where SDA is available at RW (like in the official schematics), and another one where SDA is available at J15B:E2

     

    I noticed, that the on-board 74HC595 was loaded faster than expected (ca. 750 nS instead of 1.5 uS), this could cause the unstable CS1..8 lines.

    It was faster than the SR load of J28 based DOUT chain...

    Please try it.

     

    Best Regards, Thorsten.

  4. What do you mean with:

     

    enc=1371 and enc=1372 get updated but i like them to update allready

     

    what kind of update do you expect?

     

    If you mean, that they should be handled by the .NGR script, then I would say that this is unexpected.

    Could you please add some debug messages (via the "LOG" command) to the script and doublecheck, which parts are executed?

     

    Best Regards, Thorsten.

  5. Hi Ken,

     

    first please doublecheck the firmware configuration by entering "kb 1" into the MIOS Terminal.

     

    These are the most important settings for your keyboard:

    set kb 1 note_offset 21
    set kb 1 rows 12
    set kb 1 velocity on
    

    If this doesn't already help, you could check if all DOUT outputs are toggling frequently.

    For this test, disable the scan optimisation with:

    set kb 1 optimized off

    (you can enable it later once the scan is working)

     

    Next check would be to compare the DOUT pulses with the incoming DIN pulses when a key is pressed (requires the usage of two scope channels)

    You should especially see a pulse at the Break *and* Make line if the corresponding key is fully pressed.

    And you should only see the pulse at the Break line if the corresponding key is not fully pressed.

     

    Best Regards, Thorsten.

  6. Cool! :)

     

    The homework that I take from this thread:

    - the MIDIO128 page has to be improved for users who don't configure the application via SCS (more explanations for the .MIO format)

    - add a workaround for Windows users so that no special knowledge is required (see also )

    - overwork the Wiki, so that it's clear which informations are intended for MIOS8 and MIOS32 users

     

    Best Regards, Thorsten.

  7. I'm asking for a confirmation from experienced MIDIboxers who are working under Windows:

     

    In the past, a MIOS Studio Query and .hex upload didn't work for applications which applied more than one USB MIDI port. We found out, that data transfers were working again if the Query button was pushed multiple times. The reason why this helps is still unknown (only Microsoft could help us to find the answer... no hope ;-).

     

    The proposed workaround was to install the GM5 MIDI driver, or to force MIOS32 to use a single USB MIDI port, but this resulted into unwanted quirks and limitations.

     

    Meanwhile I think that it's better to add workarounds into MIOS32 so that at least the communication with MIOS Studio is working properly under all circumstances, so that newbies (who don't know the details) don't need to be aware of this special knowledge.

     

    Therefore I added a workaround into MIOS32, which sends 256 dummy "Runtime Status" events during a Query. They are not displayed by MIOS Studio, so that nobody should notice it - but a Query should always work during startup - no need to push the button multiple times anymore!

     

    Could you please check one of following applications at your side without the GM5 driver, and without "single_usb" configured in the MIOS32 bootloader:

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

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

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

     

    After the installation, MIOS Studio should

    - always detect the core after power-cycle

    - each Query should work

    - application upload should always work

     

    if not, please let me know!

     

    Best Regards, Thorsten.

  8. Unfortunately Windows can't handle the 4 USB MIDI ports correctly, this can cause such corrupted file transfers.

    The solution is described here: http://www.ucapps.de/mios32_bootstrap_newbies.html

    Upload the Bootloader Update application, and enter

    set single_usb 1
    store
    into the MIOS terminal.

    Thereafter disconnect the USB cable, wait 5 seconds, connect again, wait until Windows has installed the driver, restart MIOS Studio.

    You will only get a single USB port anymore, but transfers should work stable again.

    Best Regards, Thorsten.

  9. It's probably less complicated then you think! ;-)

     

    It seems that you are trying to configure the MIDIO128 application according to the documentation for V1 or V2, but on your LPC17 core MIDIO128 V3 is running, which supports a much more comfortable approach.

    E.g. it isn't required to run a perl (.pl) script anymore, the application does directly read & parse the DEFAULT.MIO file from SD Card.

     

    I would propose to edit the DEFAULT.MIO file directly with the Filebrowser editor, which is integrated into MIOS Studio.

    Here a snapshot for MIDIbox SEQ where MBSEQ_HW.V4 is edited:

    mios_studio_filebrowser.png

     

    Just try the same with DEFAULT.MIO

     

    Alternatively you could download the file to your harddisk, edit with Excel or OpenOffice, and upload again to SD Card.

    midio128_v3_spreadsheet2.png

     

    In any case, please enter "load default" in MIOS Studio terminal after the file has been changed to take over the new configuration.

     

    Apart from the fact that it is a good idea to put the two matrices on a different channel: are you sure it is okay that all sr pins result in the same notes?

     

    for example I expect sr2/d0 results in a notenumber 58 (A3) and not in a notenumber 49 (C#2).

     

    I believe that you haven't enabled the matrices in DEFAULT.MIO yet - please do this first.

    First matrix: SR DIN and DOUT should be assigned to 1

    Second matrix: SR DIN and DOUT should be assigned to 2

     

    Best Regards, Thorsten.

  10. I guess that you don't want to use the snapshot function, because it would store/restore all EVENT values (which are not excluded from snapshot) into/from a single storage, right?

    There is a trick which could help in this case: you could use the SET command in a .NGR script to copy the value into dummy events, which don't listen or send to any MIDI port, but just act as storage units.

    E.g. let's say you've defined a dummy LED with:

    EVENT_LED id=3000
    Then you should be able to copy the value of encoder 1 into this Event with

    set LED:3000 ENC:1
    And copy back with:

    set ENC:1 LED:3000
    in a .NGR file

    Best Regards, Thorsten.

  11. Hi,

    yes it makes a difference, banks (resp. via .NGR activated) MIDI events are filtered earlier during the Event processing than conditions. This saves a little bit execution time, therefore banks/activate should be preferred if possible.

    Best Regards, Thorsten.

  12. Hi Robert,

    I guess that you only missed a small detail: each Matrix entry has a MIDI channel called 'Chn' (1 by default) and a Note Offset which is called 'Arg' (0x30 by default) in the configuration file which needs to be configured.

    I would propose to specify a different MIDI Channel for the second Matrix, so that you can assign a different Synth voice to it.

    Best Regards, Thorsten.

  13. Hi Martin,

    maybe I can help you to check this next week.

    However, did you know the JSynthLib based MIDIbox FM editor, which supports a Wavetable editor as well?

    I think that it is a good reference for your implementation! :)

    Here is the code: http://sourceforge.net/p/jsynthlib/code/HEAD/tree/trunk/JSynthLib/src/main/java/synthdrivers/MIDIboxFM/

    Note that MacOS users (like me) won't be able to use your tool (and we are also not able to use JSynthLib), since Apple doesn't support SysEx in Java anymore :-(

    Best Regards, Thorsten.

  14. Thank you for the hint!

     

    Lemur is especially recommended for upcoming MIDIbox CV V2 users, and for everybody who wants to create his own "tricky" panels which are not limited to sending/receiving constant OSC or MIDI messages. Especially due to the scripting capabilities it's possible to setup parsers and processing routines, which are the key for a flexible bidirectional communication between the GUI and a (MIDI) device! :)

     

     Best Regards, Thorsten.

  15. I see the Serial IN of IC2 (SR of oled1-8) is connected over 1kOhm to LCDvolt. And the Serial IN of a DOUT is not. What is the difference between those 2 use-cases of 74HC595?
    This pull-up resistor shouldn't make a difference for the SSD1306 driver (but thanks for the hint, I should doublecheck my assumption).

    It's intended for displays which work at 5V, in this case the IO pins will be configured for open drain mode, so that the resistor pulls the output level to ca. 5V. The SSD1306 driver configures IO pins for push-pull mode instead, so that they are switched between 0V and 3.3V

    ( {Thinking loud...} is it possible that that Serial input is inverted and the inversion causes a delay so the alignment of the Datalines D0,D1,DC is not coherent with the CS lines anymore, or something like that...)
    I thought that I already doublechecked this, but let me tribble check the implementation next week ;)

    My own assumption was the following: the SDA input of the SSD1306 displays was connected to J15:RW

    This pin is also connected to the OE# (Low-Active Output Enable) input of IC2

    Which means: whenever a "1" was transmitted to the displays, the 74HC595 outputs were in high impedance state for a short moment.

    Although experiments showed me, that the short high-impedance is hard to notice with a scope (and therefore would be acceptable), I'm unsure if it has a more dramatic effect once much longer cables are used (very likely...)

    Therefore in the last modification, SDA was driven from another pin, so that RW (and accordingly OE#) is always 0, and accordingly the outputs of the 74HC595 should always be active.

    I expected that this avoids the potential problem, but now you noticed an even worse effect, which really puzzles me! :-/

    However, I'm sure that we will find a solution (regardless if fully understood or not) this year! :)

    Best Regards, Thorsten.

  16. Program Changes are not properly supported for drum tracks - this would be against the concept of the parameter layer usage in this mode...

     

    For "normal" tracks, you have to set the same program change value for all steps (just press & hold the ALL button, and then set the desired program change value). MBSEQ will then only send the PC event once (whenever it's different from the previously sent value)

     

    Best Regards, Thorsten.

  17. I'm not 100% sure if the missing diode could cause a problem, but since I'm currently not able to try it without a diode at my side, please mount it.

     

    General question: did you follow the walkthrough? -> http://www.ucapps.de/midibox_sid_walkthrough.html

     

    E.g. it's important that you install MIOS (the operating system) before the MIDIbox SID application, otherwise the app won't start, and also the LCD won't be initialized (so: actually the same effect that you described)

     

    Best Regards, Thorsten.

  18. I guess that you only tried the long cable, but not the short cable to J15, right?

     

    Anyhow, although the actual issue isn't clarified (I hoped that we are able to achieve this), we should go for Plan B: connecting the 16 CS lines to two DOUT SRs which are connected to J28.

    Unfortunately I can't give you new code till next week (Merry Christmas! :smile:)

     

    Best Regards, Thorsten.

×
×
  • Create New...