Duggle

No, this is a standard LPC17 core. So the results I last posted hold for the following hardware setup consisting of only: Standard LPC17 Core with latest bootloader 1 x DINx4 module with buttons connected to 1st SR Based on this I'm suggesting a fundamental bug has been introduced sometime after V1.012

The simplest script is "empty.ngc" which consists of 1 command: RESET_HW Of course we need enable debug information by typing "set debug on" at the MIOS Studio terminal to see the notifications. I have various pre-compiled versions of MIDIbox NG in a folder: V1.012 buttons o.k. V1.019 buttons don't work V1.021 buttons don't work "Huston, we have a problem..." :rofl:

Yes, I discovered the significance of RESET_HW and have been using it like above. Until you can look at this I'll identify the simplest script that exhibits the problem, then maybe re-flash with an earlier release of NG. I can't believe something so simple isn't working (but I now know my hw is fine).

I guess the first problem to solve is the values not being updated. I'll verify this without using any LABEL constructs. On the subject of nested labels it appeared to be doing this, but could be just an artefact, so I'll play with this. I believe what you say about it not being supported nor viable.

Actually it would appear that you can have conditional labels referenced within a LABEL definition. However, a more pressing issue needs to be solved: The problem being that the value is not being updated on the LCD. In the following case it simply displays "PW 0". The debug log shows the value changing. In the default.ngc file: EVENT_ENC id= 2 hw_id = 2 fwd_id=LED_MATRIX:19 bank=1 fwd_to_lcd=1 type=CC chn= 1 range=0:127 offset=0 ports=1000100000001000 led_matrix_pattern=1 cc= 18 led_matrix_pattern=3 label="^b1e2" In the default.ngl file: LABEL b1e2 "@(1:9:2) PW %3d" In the log: [20366.614] MBNG_ENC_NotifyChange(2, -1) [20366.614] [EVENT:7002] ENC hw_id=2 bank=1 fwd_id=0x6013 type=CC value=76 label=^b1e2 [20366.614] MBNG_MATRIX_DOUT_NotifyReceivedValue(19, 1, 75) I only have the first 2 LCDs connected for this test. The other 3 fields visible on the first 2 LCD don't change either.

I've just verified that using LABEL definitions for LCD strings saves a lot of memory: around 25% in my case, that will probably mean a whole extra bank of 64 encoder LED rings, in my case. The slight downside is that the string information is split off into the .ngl file making the information dispersed and less immediately readable/editable. Now, for those LCD strings that contain conditional labels: I assume that they cannot be nested? This means that the correct way to format LCD strings is as follows: In the default.ngl file LABEL b1e12 ""@(6:9:1)Sync:" COND_LABEL on_off COND =0 "Off" COND_ELSE "On " In the default.ngc file label="^b1e12^on_off"

Ok, this is getting interesting! I've just compiled, and loaded tutorial/10_din and all the hardware works perfectly. All my DIN pcb's are working (despite some abuse- J1 of DINx4 connected reversed, resulting in some hot chips!) This is verified with the complete SRIO chain with buttons connected and all. There must be a bug in NG? The crazy thing is that it wasn't working, then after fiddling about it did work for some time, then at next power up the next day it wasn't working again. I was sure it would be hw related. So after the successful 10_din test, I just reflashed NG and the fault is back. TK, I could send you my script but the fault is demonstrated by an empty script or simple one like above. I have the latest bootloader and pre-compiled NG running in the core. As always, thanks for your help!

Should the red LED on the Xpresso pcb ever go off? (I'm finding that mine goes off at some point even though the core is still communicating over USB with MIOS Studio o.k.) I've loaded an empty.ngc file and there are no debug notifications. I find that similar to the log in the last post, only notifications of EVENT declared elements are shown, and then only upon loading the ngc, allways showing 0, and after this, no notifications are received. (I'll note here, again, that when I connect the whole SRIO chain, the Fairlightii pcbs,as well as other DOUTs are working fine!) I'm finding that when I type "help" MIOS Studio indicates that debug mode is switched on, which it isn't, until I give the command. Is this setting supposed to be "remembered"?

OK, I've main it really simple: A new DIN board with 1 SR and pullups attached as the only device on J8/9. RESET_HW EVENT_BUTTON id=1 type=NoteOn key=36 EVENT_BUTTON id=2 type=NoteOn key=36 EVENT_BUTTON id=3 type=NoteOn key=36 EVENT_BUTTON id=4 type=NoteOn key=36 EVENT_BUTTON id=5 type=NoteOn key=36 EVENT_BUTTON id=6 type=NoteOn key=36 EVENT_BUTTON id=7 type=NoteOn key=36 EVENT_BUTTON id=8 type=NoteOn key=36 heres the log: [3049.771] [FILE] Uploading /B.NGC with 314 bytes [3049.827] [FILE] Upload of 314 bytes finished. [3049.827] AUTOLOAD 'B' [3049.827] [MBNG_FILE_C] Event Pool Number of Items: 8 [3049.836] [MBNG_FILE_C] Event Pool Allocation: 208 of 24576 bytes (0%) [3049.836] MBNG_DIN_NotifyReceivedValue(1, 0) [3049.836] MBNG_DIN_NotifyReceivedValue(2, 0) [3049.836] MBNG_DIN_NotifyReceivedValue(3, 0) [3049.836] MBNG_DIN_NotifyReceivedValue(4, 0) [3049.836] MBNG_DIN_NotifyReceivedValue(5, 0) [3049.838] MBNG_DIN_NotifyReceivedValue(6, 0) [3049.838] MBNG_DIN_NotifyReceivedValue(7, 0) [3049.838] MBNG_DIN_NotifyReceivedValue(8, 0) [3049.838] Patch 'B' loaded from SD Card!

I have a DINx4 PCB in a SRIO chain followed by 4 x Fairlightii PCBs. The DINx4 with standard push buttons attached to the 1st Shift register weren't working at all, then after some fiddling (changing the PCB and back again) were working as per the script o.k. Today I power up again and it is back to as though no buttons are pressed when they are. I short Vs to D7 with screwdriver to eliminate the wiring to the buttons. I have debug on. Should I see a notification in MIOS Studio when a button is toggled? The Fairlightii PCB continue to work, so I know data is being shifted through the SRs of the DINx4 module. I'm using the this bit of script with the buttons, which is the same if I isolate it and run just it. The script has worked so I know it's not that. Any ideas on how to debug? EVENT_BUTTON id=8 fwd_id=LED:33 type=Meta meta=SetBank button_mode=OnOnly range=1:1 radio_group=1 value=1 EVENT_BUTTON id=7 fwd_id=LED:34 type=Meta meta=SetBank button_mode=OnOnly range=2:2 radio_group=1 EVENT_BUTTON id=6 fwd_id=LED:35 type=Meta meta=SetBank button_mode=OnOnly range=3:3 radio_group=1 EVENT_BUTTON id=5 fwd_id=LED:36 type=Meta meta=SetBank button_mode=OnOnly range=4:4 radio_group=1 #####Patch Controller dump request###### EVENT_BUTTON id=4 fwd_id=LED:37 button_mode=OnOnly type=SysEx stream="0xf0 0x00 0x20 0x33 0x01 0x00 0x37 0x00 0x40 0xf7" EVENT_BUTTON id=3 fwd_id=LED:38 type=NoteOn key=45 value=0 EVENT_BUTTON id=2 fwd_id=LED:39 type=NoteOn key=47 value=0 EVENT_BUTTON id=1 fwd_id=LED:40 type=NoteOn key=48 value=0 MIOS Studio terminal has this output upon loading the script, but nothing after this: [5594.825] load buttons [5594.843] [MBNG_FILE_C] Event Pool Number of Items: 8 [5594.843] [MBNG_FILE_C] Event Pool Allocation: 244 of 24576 bytes (0%) [5594.843] MBNG_DIN_NotifyReceivedValue(8, 1) [5594.843] MBNG_DOUT_NotifyReceivedValue(33, 1) [5594.844] MBNG_DIN_NotifyReceivedValue(7, 0) [5594.844] MBNG_DOUT_NotifyReceivedValue(34, 0) [5594.844] MBNG_DIN_NotifyReceivedValue(6, 0) [5594.844] MBNG_DOUT_NotifyReceivedValue(35, 0) [5594.844] MBNG_DIN_NotifyReceivedValue(5, 0) [5594.845] MBNG_DOUT_NotifyReceivedValue(36, 0) [5594.845] MBNG_DIN_NotifyReceivedValue(4, 0) [5594.845] MBNG_DOUT_NotifyReceivedValue(37, 0) [5594.845] MBNG_DIN_NotifyReceivedValue(3, 0) [5594.845] MBNG_DOUT_NotifyReceivedValue(38, 0) [5594.846] MBNG_DIN_NotifyReceivedValue(2, 0) [5594.846] MBNG_DOUT_NotifyReceivedValue(39, 0) [5594.846] MBNG_DIN_NotifyReceivedValue(1, 0) [5594.846] MBNG_DOUT_NotifyReceivedValue(40, 0) [5594.846] Patch 'buttons' loaded from SD Card!

I'm deeply into building an absolute beast of a midibox NG. It has a SRIO chain consisting of 2 x DOUTx4 modules, a DINx4 module, followed by 4 x Fairlightiii 8x2 Encoder LED rings PCBs. After attaching the 3rd and 4th Fairlightii PCB, all the LED rings started to flicker! I soldered in-line a 100R resistor on the SCLK signal (bottom resistor in Thorstens photo). I didn't insert the other resistors shown below, just the one on the SCLK. This fixed it! :frantics: WooHoo!

Thanks Thorsten. This NG stuff is very powerful, and sometimes difficult to explain. Over time, with gradual enhancements to the doco and further examples it will get clearer. Happy to report everythings working well at this at this end!

Do you mean before when I had led_emu_id_offset=1? The additional description that you have since added, helps. I might have expected LED:1 to work instead it's LED:33 to address the first standard LED in my set up. I'm not sure there is any indication of this (or rather the logic behind this) in the manual.

I'm not sure, TK, because the particular issue is hit when dealing with combinations of display elements: LED Matrix followed by standard LEDs. Otherwise I might have suggested a note where "fwd_id" is explained but this would only complicate that section. I can only suggest a paragraph in the examples somewhere, explaining that the LED indexing is done by DOUT pins and not LED Matrix Elements which is what I (wrongly) predicted.

O.K, getting clearer, still! EVENT_BUTTON id=1 fwd_id=LED:33 type=NoteOn key=36 value=100 works because there are 32 SR DOUT bits before the first standard LED. Perhaps the documentation should explain the counting logic to make it clearer (or perhaps I missed it).

Thanks Thorsten, it's getting a little clearer. The RGB LEDs are working perfectly with the following script, but no sign of action on the next DOUT SR in the chain, I'm looking for something on D7. DOUT_MATRIX n=1 rows=8 inverted=1 sr_dout_sel1=1 sr_dout_r1=2 sr_dout_g1=3 sr_dout_b1=4 led_emu_id_offset=1001 EVENT_RECEIVER id=1 type=CC cc=16 fwd_id=SENDER:1 EVENT_SENDER id=1 type=Meta meta=SetBank EVENT_BUTTON fwd_id=LED:65 type=NoteOn key=36 value=100 # Bank1 #1st row EVENT_LED id=1001 bank=1 rgb=15:0:0 value=100 EVENT_LED id=1002 bank=1 rgb=15:3:0 value=100 EVENT_LED id=1003 bank=1 rgb=15:7:0 value=100 EVENT_LED id=1004 bank=1 rgb=15:15:0 value=100 EVENT_LED id=1005 bank=1 rgb=7:15:0 value=100 EVENT_LED id=1006 bank=1 rgb=3:15:0 value=100 EVENT_LED id=1007 bank=1 rgb=3:15:3 value=100 EVENT_LED id=1008 bank=1 rgb=0:15:0 value=100 #2nd row EVENT_LED id=1009 bank=1 rgb=0:0:15 value=100 # Bank2 EVENT_LED id=1001 bank=2 rgb=15:15:15 value=100 EVENT_LED id=1002 bank=2 rgb=15:15:15 value=100 EVENT_LED id=1003 bank=2 rgb=15:15:15 value=100 EVENT_LED id=1004 bank=2 rgb=15:15:15 value=100 EVENT_LED id=1005 bank=2 rgb=15:15:15 value=100 EVENT_LED id=1006 bank=2 rgb=15:15:15 value=100 EVENT_LED id=1007 bank=2 rgb=15:15:15 value=100 EVENT_LED id=1008 bank=2 rgb=15:15:15 value=100 EVENT_LED id=1009 bank=2 rgb=15:15:15 value=100

I must confess, I don't understand yet. I have built the full 8x8 RGB matrix. (actually only the first 4 rows of 8 LEDs are loaded - supply delay...) The only way I can get it to work right is with DOUT_MATRIX n=1 rows=8 inverted=1 sr_dout_sel1=1 sr_dout_r1=2 sr_dout_g1=3 sr_dout_b1=4 led_emu_id_offset=1 EVENT_LED id=1001 fwd_id=LED:1 bank=1 rgb=15:0:0 value=100 EVENT_LED id=1002 fwd_id=LED:2 bank=1 rgb=15:3:0 value=100 EVENT_LED id=1003 fwd_id=LED:3 bank=1 rgb=15:7:0 value=100 #etc counting upwards until EVENT_LED id=1032 fwd_id=LED:32 bank=1 rgb=15:7:0 value=100 It doesn't seem to matter if they all have id=1001 Now, If I have led_emu_id_offset=1001 (and the id=nnn with nnn counting up from 1001) I am not uniquely addressing rows, values are folded over such that all 4 rows show the same pattern of colours. Bearing in mind, the aim is that these LEDs don't respond to MIDI events as such, they simply each change to a unique state based on the currently selected bank... I'd like to ask about the 32 standard LEDs that are wired to a DOUTx4 module that comes after RGB DOUTx4 module in the SRIO chain. I've tried to address them with EVENT_BUTTON fwd_id=LED:65 (counting up) seemingly without luck. Am I on the right track? The next devices on the SRIO chain are 4 x Fairlightiii 2x8 encoder pcb's. I think the configuration of these will be straight forward if I put the correct SR number assignments for the encoders and DOUT_MATRIX's ?

Quick question: Is it possible to evaluate constant expressions with the preprocessor?

I updated the application to NG 1.020 from the precompiled zip. After disconnecting the core and restarting MIOS Studio, the 4 USB devices appear, but Query does not work on any of them. I run the GM5 installer and uninstall. Now MIOS Studio can communicate with the Core and 4 USB devices appear, but the File Browser fails during opening a file for edit. I run the "Install KORG USB-MIDI Device" from the start menu, "ERROR: No Device plugged in" I select "unistall" for MIDbox NG device in Device Manager I run the "Install KORG USB-MIDI Device" from the start menu, "Allow Hardware Wizard to run", or similar The device enumerates and shows MIDIbox NG in device manager I run the "Install KORG USB-MIDI Device" from the start menu, "ERROR: No Device plugged in" So unfortunately I am unable to actually install the KORG driver :-( To restore things to functional again I have had to reflash the Core with single USB device firmware build NG using UART midi from a GM5 Interface module. I'll also mention an interesting observation, with the GM5 drivers: Both the Core USB devices and the GM5 module appear as "MIDIbox NG" which was very confusing at first. This also occurred with 4 USB midi device version of NG and the GM5 module with the windows drivers,(If I am not going completely mad....which is conceivable ;-) . Now that I am back to my single USB device build NG with the windows drivers I see "MIDIbox NG" (x1) and "[2] Ploytec GM5 www.midibox.org" as I should and it's all working fine.

That's really cool. I'm not sure whether my Synths (Virus B and C) can do anything with release velocity, perhaps Native Instruments VSTi do? I have a MBKB with a dual Fatar 66 keybeds. Anyhow, well done.

What I'm seeing is this: With MIDIbox KB and SEQV4 (LPC17), as I described will use GM5 driver if plugged into a certain USB port, Windows drivers if plugged into another. Then, if I swap the USB ports they are plugged into, the drivers also swap. From this it would seem that the GM5 driver associates itself with a certain physical that was used during it's installation. I could try installing GM5 on the other port out of curiosity sometime. What I do notice is that the File Browser functionality is more profoundly defunct using GM5 rather than Windows Drivers (i.e both faulty with slightly different signs and symptoms)

I've noticed the same thing with a second core using Windows drivers instead of GM5. I think it came down to which physical USB socket I plugged into in the PC, in my case. Definitely make sure you have the latest bootloader (1.010, I think it's called). In my case this improved the handling of multi USB port applications to the point where I could route different USB ports to different MIDI ports on my SEQV4 handling MIDI events and SysEx perfectly for the first time. However, the File Browser does not work right in this set up. I had the same problem on my NG core on another PC, (I found, naturally, that no File Browser with NG was totally unacceptable, so I recompiled for 1 USB port and now all is fine). So to answer your question, my advice is to update your bootloader, and then load the app build that has just 1 USB port enabled.

By all means build another core and see if you have the same problem... BUT...There are still real problems with USB drivers under windows. They only affect sdcard operations as far as I know, and are solved by having only 1 USB port enabled in the firmware. The pre compiled binary has 4 ports enabled...

There are USB driver issues in Windows, still. I have had problems with all drivers (GM5, Windows, Korg). The most recent Bootloader fixed some of the issues, but I'm still having problems with the File Browser functionality *unless* I recompile the app for *one* USB port (not four). Typically the file transmissions fail during transfers related to editing a file. From memory, I have this experience with applications: SEQ V4 and NG, on OS's: Windows 7 x64 and WinXP. For simplicity, we might ask TK to include a binary with only one USB port enabled in the pre-compiled zip for MIDIbox NG? Having said all of that, I don't know that it will fix the current problem of this thread, but it is something that needs to be eliminated anyway.

Try re-starting MIOS Studio *after* you connect the USB to the core. Are you using PC or OSX?