RGB colour matrix (8x8)

MIDIbox NG
1

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.

2

I will spend some thoughts on this topic this weekend.

Currently we’ve a more important topic to discuss via email :wink:

 

Best Regards, Thorsten.

3

I’m out of the context but where can I found information about the 64 encoders led ring you mentioned in the beginning of your post please ?

4

http://discourse.midibox.org/t/topic/17220

5

Awesome thx !

 

I just sent a mail to  fairlightiii to know if he still have some of these PCB.

 

Ender

6

Hi TK,

just a gentle bump on this topic :rolleyes:

Any thoughts?

Thx

7

I will work on this tomorrow. :smile:

 

But to give you already some informations:

  • after the KB driver has been integrated into MBNG, the scan rate is ca. 4 kHz (250 uS), and not only 1 kHz (1 mS) anymore

  • I gave up the idea to support a second SRIO for various reasons

  • MBNG won’t support a matrix where RGB LEDs are connected this way! Each color needs a dedicated SR (BLM_SCALAR design). Alternative scramblings would make the configuration interface too complicated. I also want to prevent, that somebody starts a PCB based on such a wiring and than forces me to support it for other MIDIbox firmwares as well, although I can’t test it -> reduce complexity!

  • I will start with 16 brightness levels for LEDs directly connected to DOUT pins (w/o matrix) based on the MIOS32_SRIO enhancement that you proposed some time ago (actually the paging can also be used to offload the matrix drivers by storing the patterns directly into the pages)

  • next step would be to support this also for matrices with 3 levels only

 

Best Regards, Thorsten.

8

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!

9

The most important step has been done: I added MIOS32_SRIO_NUM_DOUT_PAGES to MIOS32_SRIO.

 

And I overworked the MBNG DIN/DOUT matrix handler, so that it stores the selection and output patterns in these pages.

 

As a result, the RAM consumption is a bit lower (no “double-buffering” anymore), but more important: the CPU doesn’t need to copy the next patterns into the DOUT registers with each update cycle anymore.

 

So: a big performance benefit + dimmed LEDs for free! :wink:

 

Best Regards, Thorsten.

10

WooHoo! :frantics:

11

Everything implemented in V1.019 :slight_smile:

 

Best Regards, Thorsten.

12

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!

 

 

 

 

13

You are right - I fixed this in the repository (/edit: and now also in the prebuilt v1.019 binary)

 

Note that EVENT_LED_MATRIX automatically provides access to each pin with cc=16, 17, 18, …, not only a single pin.

Accordingly, the colours should be assigned to the same cc (set cc=16 for all three EVENT_LED_MATRIX commands)

If still individual control is desired, use different channels for each colour - or enhance the maps.

 

Best Regards, Thorsten.

14

All good now, thanks TK!

 

The 8 row option gives a good range of hues, so I’ll be using it instead of the 4 row (which would be messy to wire, and it’s getting busy wiring wise!)

 

I’ve tested a setup similar to the example, the triplet r,g,b  is referenced as a single CC using 3 EVENT_LED_MATRIX.

 

The way I want to use it is when a bank is selected with a push button, each RGB LED goes to a particular hue according to how the bank has been defined.

 

So a bank change will result in each of 64 RGB LED’s changing it’s colour. How do I define this in ngc?

15

Ok, I see…

 

The solution in V1.019 only allows to change the hue individually for each LED.

But in V1.020 a new “unicolour” mode will be available which allows to set the levels for all LEDs of a matrix via Meta events.

 

You can already try out the changes by compiling the latest version in the repository.

 

The “unicolr.ngc” file shows, how you can control the levels with CC#16, #17 and #18 by using the SetColour[RGB]FromValue event:

http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Funicolr.ngc

It’s nice for finding out the best matching levels.

 

And the “unicolr2.ngc” file demonstrates your usecase:

http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Funicolr2.ngc

 

Each bank change will call the meta events SetColour[RGB] to set the brightness levels

 

Note that with this solution, it’s possible to use different hues for the different matrices! :smile:

 

Best Regards, Thorsten.

16

unicolr2.ngc looks as though it sets all LEDs to the same selected hue with a bank change?

 

Perhaps I didn’t explain my usecase properly:

When I’m designing a bank for the synth, I may wish to have different hues for different parameters (or groups of parameters) e.g. each OSC1 related parameter purple, and each OSC2 parameter light green, etc,etc within the same bank.

Then with a change of bank, again each newly displayed parameter may have it’s own particular hue, etc. 

17

Ok, in this case we’ve to store the set of brightness levels in each EVENT item. This will increase the memory consumption, however I will add this tomorrow…

 

Best Regards, Thorsten.

18

I replaced the “unicolour” feature (+ meta events) by a rgb parameter which can be specified in the EVENT_* definition.

 

Usage examples:

  • rgb values directly defined for 64 LED events: rgb_1.ngc
  • rgb values forwarded to LEDs via button events: rgb_2.ngc
  • rgb values defined in banked button/led events: rgb_3.ngc

Best Regards, Thorsten.

19

Can’t access the repo due to lack of response from host:-(

 

In the meantime, for testing, how can I trigger bank change with midi keys?

 

 

EVENT_BUTTON id=2000 type=Meta meta=SetBank button_mode=OnOnly range=1:1 lcd_pos=1:1:2 label="Bnk%q"
EVENT_BUTTON id=2001 type=Meta meta=SetBank button_mode=OnOnly range=2:2 lcd_pos=1:1:2 label="Bnk%q"

 

i.e. can I forward midi key event to (non-existant) button definitions like above?

 

20

Unfortunately the strange firewall protection will prevent you from updating the SVN. :frowning:

 

Here is a temporary binary release: http://www.ucapps.de/mios32/midibox_ng_v1_020_pre1.zip

 

 

Bank Change: currently I don’t see a way to select banks from external MIDI keys, because there is no mechanism to convert the key number to a “value” which then will be forwarded to a SetBank meta event.

 

However, here an example how you could change the bank from a CC:

EVENT_RECEIVER id=1 type=CC cc=0 fwd_id=SENDER:1
EVENT_SENDER id=1 type=Meta meta=SetBank

 

Best Regards, Thorsten.