Duggle

I've setup a test for the 8x8 configuration: RESET_HW DOUT_MATRIX n=1 rows=8 inverted=1 sr_dout_sel1=1 sr_dout_r1=2 sr_dout_g1=3 sr_dout_b1=4 MAP1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 MAP2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 MAP3 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #test first LED by CC for r,g,b EVENT_LED_MATRIX id=1 hw_id=1 colour=0 type=CC cc=16 chn=1 dimmed=1 range=map1 EVENT_LED_MATRIX id=2 hw_id=1 colour=1 type=CC cc=17 chn=1 dimmed=1 range=map2 EVENT_LED_MATRIX id=3 hw_id=1 colour=2 type=CC cc=18 chn=1 dimmed=1 range=map3 To simply control each r,g,b LED with a CC. Red and green work as expected (off+3levels) Blue does not work. I get this when loading: [4633.602] AUTOLOAD 'DL' [4633.602] [MBNG_FILE_C] ERROR: invalid flag in EVENT_LED_MATRIX ... colour=2 (expect 0..2) [4633.602] [MBNG_FILE_C] Event Pool Number of Items: 2 [4633.604] [MBNG_FILE_C] Event Pool Allocation: 146 of 24576 bytes (0%) [4633.608] Patch 'DL' loaded from SD Card!

WooHoo! :frantics:

Sounds great: >>>>- after the KB driver has been integrated into MBKB, the scan rate is ca. 4 kHz (250 uS), and not only 1 kHz (1 mS) anymore Cool! >>>>Each color needs a dedicated SR (BLM_SCALAR design) No problem, I haven't built anything (yet) >>>>- next step would be to support this also for matrices with 3 levels only This will be useful!

I think this is simple, but I'm not sure how it's done: Assuming I have a group of radio buttons and LEDs controlling the current Bank, how do I have the Bank change bring up an LCD text label for that Bank? Thanks

Quickly skimming this thread: Did you realise MIDIbox NG does run on a STM32 core (if you flash the appropriate binary, of course). If there is a logic control config available then I'd definitely look at this route. [edit] o.k, so you're currently using a 8 bit core, in that case a new LPC core would be handy!

What is "best" depends on your own criteria For example: Do you want to minimise building effort? (In that case I'd just plug midi from the keyboard into NG core, and concentrate on the functionality of the controller) Is aesthetics important? then perhaps you may want to build it all into one device, etc. From a technical point of view, knowing the key switch arrangement would be essential for getting the keyboard controller working. It will all take time, so I'd suggest even if you want to do the keyboard control part with NG, perhaps starting with the Logic controller part, then a later step to interface the keyboard.

Hi TK, just a gentle bump on this topic :rolleyes: Any thoughts? Thx

It works really well. if you start a comment line with "#", then a warning/error is printed to the console as the pre-processor is expecting a directive. If you start a comment line with "##" the warning/error is generally removed and the whole comment line appears in the output file. If there is an apostrophe(') in the comment this generates a warning. If you start a comment line with #// this removes such a warning, but the comment line will not appear in the output file. The pre-processor inserts a few "comments" itself in the output file to indicate certain things such as where an include file has been inserted, but these always begin with # so are happily ignored by NG! I'm very glad to use the pre processor as it allows to break up a huge *.ngc into smaller components that can be named appropriately, I'm now exploring how #defines can be used to streamline, save typing, and provide more global control e.g easily replace values, etc.

That's really interesting, and good to know!

Is it possible, or desired, or will it ever be implemented: something like #include "myfile.ngc" where another ngc file (myfile.ngc in this example) gets inserted in the containing file. something like #define mysymbol XYZ where text is substituted (in this example wherever mysymbol is encountered it is replaced by XYZ) I understand that the internals of NG really determine if these features are even practical possibilities let alone whether they are desirable or not. I think they would be very useful to have.

The *.ngc file posted has #bank 1, #bank 2, etc, written above each group of definitions. But there are no actual banks defined, right?

That's a good idea!

Yes, that would work fine and the price is o.k I've just wired up a bus of 20 of a similar looking LCD and I can tell you I would try to hunt down an LCD with 2 rows of 8 pins connector rather than 1 row of 16!!!! The 2x8 connectors are available in IDC format which would have saved me many hours of stripping, joining, and soldering grey ribbon cable to make a bus of 20 LCDs. I recon I could have saved myself about 12hours and ended up with a neater result using displays with IDC connection.

It was a case of having the LCDs sit in alignment with the encoders. It seemed that larger displays could not be arranged so that they lined up with the encoders very well (as I recall...). I'm in construction of this beast at the moment. The 2x16 LCD aligns with 2 encoders fairly well (with a 5mm gap between LCD PCBs).

Its using 4x Fairlightiii 16 Encoder LED ring PCBs like this:

I'd like to have an RGB LED beside each encoder in my 64 Encoder LEDring MIDIbox NG beast. An 8x8 colour matrix can easily be driven by a single DOUTx4 module. 1SR drives the 8 cathode rows, and remaining 3SR's drive the red,green, and blue anodes. Here's a circuit: If the standard SRIO scan rate is used, then each row is illuminated for 1ms each 8ms. This equates to 125Hz refresh rate. To obtain different colours we need to adjust the brightness of red, green and blue separately. This can be done by varying the "on" versus "off" time for each element R,G,B. Say we call each 8 row scan a "frame". By displaying 2 frames alternately, every R,G,B LED in the array has 3 "brightness" levels. It can be off for both frames (0%). It can be on in one of the frames (50%) It can be on for both frames (100%) This scenario gives us a mighty palette of 3*3*3=27 "colours" (including "off") Because it takes 16ms to display both frames, then the refresh rate is 62.5Hz. Any slower and there will be discernible flicker. If we were able to somehow double the scan rate (with 4 frames) we could have 5*5*5=125 "colours". This would be useful, I feel, as it would be a wide range of hues with variable brightness. Question now is, how could such a setup be supported by NG? Would it be possible to have a separate SRIO port running at a higher scan rate? It is possible to represent each frame as a bitmap, and to have the DMA interrupt change memory pointer to alternate frames each scan cycle, so that there is no continuous CPU load. Could NGC have a way of specifying an (R,G,B) triplet to a specific array LED? etc,etc. [edit] changed the schematic from "sharemedia" to an "imagelink", schematic is unchanged.

My take on this kind of idea I call "minicore". It's a STM32F103RET6 ($7) on an SMD adaptor PCB ($0.90), from Futurlec. It runs MIOS32 great, as it should. The nice thing about the adaptor is that you only put the interfaces on the underlying veroboard that you need for the project. I have a development baseboard (pictured) with connectors such as JTAG (for flashing a bootloader or debugging) that wouldn't normally be needed on a "finished" item. So the finished adaptor and baseboard would not need to be much larger than the SMD adaptor itself in many cases. Very economical in both cost and size!

That's a really nice encoder! Pity about the cost.

Hi TK, I'm currently using 16 encoders beside 2x40x2LCD plus 8 bank button/leds and 7 other buttons. [85522.128] Event Pool Number of Items: 143 [85522.128] Event Pool Allocation: 8235 of 24576 bytes (33%) What I'm actually aiming for is 4 banks of 64 encoder led rings +some buttons and LEDs.

yep, that has done the trick. Thanks!

I've set up a radio group of bank select button/LEDs. When I load the *.ngc the state defaults to the first bank. That's fine but the first LED is initially off. Is there a way to set the default state of the LED so it matches the default state of the bank?

OK, when I remove the duplicate EVENT_ENC lines it works as expected!

I've got NG going with a newly built core and some old hardware I had lying around. There are 2 2x40LCDs and 16 encoders on SR1 to 4. I'm able to execute the exercises in section "Rotate Me" and "Encoder Send MIDI now". However the sections "Display Me" and Toy Me" are not giving the expected results: With the code of "Display Me" pasted at the bottom of my file: I get: "ENC # 8 0_ " and nothing else displayed on LCD #1, and the debug window shows after moving encoder #1: [7798.626] [EVENT:7001] ENC hw_id=0x7001 bank=0 fwd_id=0x0000 type=CC value=1 label= [7798.736] MBNG_ENC_NotifyChange(1, 1) [7798.736] [EVENT:7001] ENC hw_id=0x7001 bank=0 fwd_id=0x0000 type=CC value=2 label= [7799.437] MBNG_ENC_NotifyChange(1, 1) [7799.437] [EVENT:7001] ENC hw_id=0x7001 bank=0 fwd_id=0x0000 type=CC value=3 label= [7799.499] MBNG_ENC_NotifyChange(1, 1) [7799.499] [EVENT:7001] ENC hw_id=0x7001 bank=0 fwd_id=0x0000 type=CC value=4 label= [7800.083] MBNG_ENC_NotifyChange(1, 1) [7800.083] [EVENT:7001] ENC hw_id=0x7001 bank=0 fwd_id=0x0000 type=CC value=5 label= here's the *.ngc file in it's entirety: RESET_HW LCD "%CEncoder Test" ENC n= 1 sr=1 pins=0:1 type=detented1 ENC n= 2 sr=1 pins=2:3 type=detented1 ENC n= 3 sr=1 pins=4:5 type=detented1 ENC n= 4 sr=1 pins=6:7 type=detented1 ENC n= 5 sr=2 pins=0:1 type=detented1 ENC n= 6 sr=2 pins=2:3 type=detented1 ENC n= 7 sr=2 pins=4:5 type=detented1 ENC n= 8 sr=2 pins=6:7 type=detented1 ENC n= 9 sr=3 pins=0:1 type=detented1 ENC n= 10 sr=3 pins=2:3 type=detented1 ENC n= 11 sr=3 pins=4:5 type=detented1 ENC n= 12 sr=3 pins=6:7 type=detented1 ENC n= 13 sr=4 pins=0:1 type=detented1 ENC n= 14 sr=4 pins=2:3 type=detented1 ENC n= 15 sr=4 pins=4:5 type=detented1 ENC n= 16 sr=4 pins=6:7 type=detented1 EVENT_ENC id=1 type=CC chn= 1 cc= 16 EVENT_ENC id=2 type=CC chn= 1 cc= 17 EVENT_ENC id=3 type=CC chn= 1 cc= 18 EVENT_ENC id=4 type=CC chn= 1 cc= 19 EVENT_ENC id=5 type=CC chn= 1 cc= 20 EVENT_ENC id=6 type=CC chn= 1 cc= 21 EVENT_ENC id=7 type=CC chn= 1 cc= 22 EVENT_ENC id=8 type=CC chn= 1 cc= 23 EVENT_ENC id=9 type=CC chn= 1 cc= 26 EVENT_ENC id=10 type=CC chn= 1 cc= 27 EVENT_ENC id=11 type=CC chn= 1 cc= 28 EVENT_ENC id=12 type=CC chn= 1 cc= 29 EVENT_ENC id=13 type=CC chn= 1 cc= 30 EVENT_ENC id=14 type=CC chn= 1 cc= 31 EVENT_ENC id=15 type=CC chn= 1 cc= 32 EVENT_ENC id=16 type=CC chn= 1 cc= 33 EVENT_ENC id=1 type=CC chn= 1 cc= 16 lcd_pos=1:1:1 label="ENC #%3i %3d%B" EVENT_ENC id=2 type=CC chn= 1 cc= 17 lcd_pos=1:1:1 label="ENC #%3i %3d%B" EVENT_ENC id=3 type=CC chn= 1 cc= 18 lcd_pos=1:1:1 label="ENC #%3i %3d%B" EVENT_ENC id=4 type=CC chn= 1 cc= 19 lcd_pos=1:1:1 label="ENC #%3i %3d%B" EVENT_ENC id=5 type=CC chn= 1 cc= 20 lcd_pos=1:1:1 label="ENC #%3i %3d%B" EVENT_ENC id=6 type=CC chn= 1 cc= 21 lcd_pos=1:1:1 label="ENC #%3i %3d%B" EVENT_ENC id=7 type=CC chn= 1 cc= 22 lcd_pos=1:1:1 label="ENC #%3i %3d%B" EVENT_ENC id=8 type=CC chn= 1 cc= 23 lcd_pos=1:1:1 label="ENC #%3i %3d%B"