Request help with *.ngc

[Duggle]

Hi MIDIBoxers,

 

I'd like to enhance my MackieControl emulation LCD display.

The motorfaders, encoders and buttons are provided by my BCF2000 and I use a core with 2x 40*2 CLCD to receive midi thru off the BCF2000 in Mackie mode. The text labels really enhance the BCF2000!

I use the logictrl.ngc template with the first 4 EVENT_RECEIVERs commented out because the BCF2000 handles these responses.

 

The unit has been of great service for a long time.

 

I would now like to implement the VU meters as a simple bar graph on the LCD there is plenty of room e.g character below and to the left of the channel label string. 

Reverse engineering the protocol, I find that the aftertouch message: D0 cv represents the VU metering.

c is the mixer channel 0 through 7

v is the VU level 0 to C (D=n/a, E=set clip, F=clear clip)

 

So I'm trying to implement EVENT_RECEIVER(s) but I'm not sure how to access and separate the data fields of cv.

There is plenty of RAM available on the core.

Help very much appreciated.

 

PS: If I can get this much working I'd probably want to improve it to use 2chars vertically for taller bargraph.

 

[edit] the aftertouch is D0 (rather than B0)

corrected definitions for v, according to the NG source code

Edited June 8, 2015 by Duggle

[TK.]

Hi Duog,

 

this was easy to implement in the dedicated "MIDIbox LC" application, but somehow it conflicts with the concepts behind MBNG.

 

There are actually two problems, one has been solved.

 

1) (the solved one): meter values have to be decoded, and they have to be animated (!) - the protocol expects that each 300 mS the meter value is decremented by 1 until 0 is reached again. Mackie implemented this to save some MIDI transfer overhead.

This is implemented in mbng_event.c (search for LCMeter) and can be used for LED matrices

 

2) (the unsolved one): animated bars haven't been considered in the display output routine. An extension is required which handles the meters like a frequently updated display element. It's probably easier just to provide such a feature as a single, configurable display element with following parameters: X/Y position, number of bars to be displayed, horizontal or vertical representation, offset between the bars

 

Best Regards, Thorsten.

[Duggle]

Hi TK,

 

Thanks,

 

I just discovered the logictrl.ngc template I was using pre-dated the LC_METER_PATTERN feature!

 

I had thought of some kind of LED meter but was attracted to the LCD because it would make use of unused CLCD display real estate and require no hardware construction.

 

I suppose the LC_METER_PATTERN only works with simple DOUT matrix not RGB? Because I haven't much space for a bar graph, I was thinking of an RGB that would display a rainbow of colours and intensities with maybe one extra red LED for clip. Actually, as I type I'm having an idea to implement this with without sw modification:

As there are (up to) 16 rows that determine the output pattern for 16 VU meter levels, the idea is to "decode" the 16 rows into 3 rows RGB with a diode and resistor of each input row. Here's a schematic:

 

Of course I would use the LCD meter option should it become available anyway because even with the LEDs, the character display is not completely spatially aligned with the BCF2000 channel strips.  

   

 

 

 

[latigid on]

Any thoughts on just using three pins with PWM control?

[TK.]

The brightness won't be good enough with this method, because (I assume) that you still want to multiplex the LEDs.

 

It's possible to set the RGB value of all LEDs which belong to the DOUT matrix row with up to 8 dim levels (actually a feature that you requested some time ago!), but hues for individual LEDs of a meter are not supported.

 

See also mbng_matrix.c:

    if( item->flags.led_matrix_pattern == MBNG_EVENT_LED_MATRIX_PATTERN_LC_AUTO ) {
      if( item->rgb.ALL ) {
        MBNG_MATRIX_DOUT_PatternSet_LC(matrix, item->flags.colour, row, item->value, item->rgb.r);
        MBNG_MATRIX_DOUT_PatternSet_LC(matrix, item->flags.colour, row, item->value, item->rgb.g);
        MBNG_MATRIX_DOUT_PatternSet_LC(matrix, item->flags.colour, row, item->value, item->rgb.b);
      } else {
        MBNG_MATRIX_DOUT_PatternSet_LC(matrix, item->flags.colour, row, item->value, NUM_MATRIX_DIM_LEVELS-1);
      }

it would be required to overwork the concept how patterns are defined

The RGB pattern feature would also cost some memory, therefore it could only be supported for STM32F4

 

Alternatively just hack your ideas into the code ;-)

 

Best Regards, Thorsten.

[Duggle]

Any thoughts on just using three pins with PWM control?

First of all, I've had great results in the past with NG RGB support (an application of PWM, or pulse density modulation in the case of NG, I think), and that's with 64 RGB LEDs  used to "colour code" control elements on a large MIDIbox. 

 

The idea I presented here only requires a total of 15x(1N4148 or similar) signal diodes. What you get is fairly precise colour and intensity for the 8 LED's with each of the 15 levels of VU which is presented as a colour gradient with respect to VU level.

This is done without modifying the sw, just specifying the RGB for each VU level in the default.ngc using the existing LC_METER_PATTERN statements:

LC_METER_PATTERN pos= X  pattern=RRRRRGGGGGGBBBBBBV

where X has values 0..15,(VU levels) and O (clip)

pattern has values (0..1) for R,G,B (5bits each), and V is the position of the clip LED.

 

The brightness won't be good enough with this method, because (I assume) that you still want to multiplex the LEDs.

There are only 8 RGB LEDs involved. I've had very good results previously with RGB (multiplexed by 8 columns) with NG in the past. (I should post a video of my last NG project with RGB LEDS)

In this instance there will be 5 pins driving each R,G,B element (albeit with a higher resistances on the additional pins) It should be at least x2 brighter than the standard bar graph LEDs.

Unless I'm wrong of course, but it is an easy experiment so I'll certainly let you all know how it goes. 

[Duggle]

After looking at the NG source code, the protocol is corrected in the initial post of this thread.

 

This means there are only 12 levels of VU and this input range is scaled across the 16 levels of "pos" in the LC_METER_PATTERN statement.

 

LC_METER_PATTERN pos= X  pattern=RRRRGGGGBBBBV000

 

So only 12 blocking diodes required.

 

My main host is Ableton which, according to the Midi Remote script for Mackie Control, simply outputs 0 to 12 (no clip or reset of clip state that I can see...). In this case I'll probably define the clip LED to come on at the same time as maximum VU (=12, that's C) but that's defined in the default.ngc which is easy to change...