Display options

[Duggle]

I remember seeing (can't find it now), a list of LCD size versus number of displays simultaneously driven by an NG app.

What are the current design limits for number/size of character LCDs supported?

[TK.]

This was discussed but it's good to create a separate thread for this topic.

 

I've prepared MBNG for 255 LCDs - but the electrical connections will be a challenge, because you won't be able to connect them in parallel without decoupling and "amplifying" the signals. Also the selection lines would have to be multiplexed - somehow - this will be difficult to handle.

The RAM for the LCDs is limited to 512 characters, which means that 64 2x16 LCDs could be handled, or 32 2x16 LCDs, or 25 2x20 LCDs, or 12 2x40 LCDs (I don't want to count the GLCD combinations ;-))

/edit: buffer size has been increased meanwhile - see documentation: http://www.ucapps.de/midibox_ng_manual_lcd.html

 

The LCD size configuration isn't implemented yet - and currently it's especially only possible to use 2 (G)LCDs with up to 64x4 characters. I will work on a more flexible configuration next year.

 

The electrical part will be a challenge - it will probably require dedicated solutions depending on the LCD types being used.

So: only recommended for experts who know how to develop the appr. circuits, and would directly implement & test the LCD driver by themself.

 

Current state in v1.010: still only 2 E(nable) lines supported for CLCDs - I have to reserve some time to go through the detailed planning/implementation/documentation process - but my vacation is over. So, maybe next weekend ;)

 

Best Regards, Thorsten.

[Duggle]

255 LCD's amazing! 512 characters less so :huh:

What number of CLCD do you see as the upper limit before electrical buffering is necessary?

 

I take it that the buffering would consist of the LCD output J15 driving a number (say 4) inputs of non-inverting buffer for each signal of the LCD bus? (Assuming the buffer can drive 4 LCD's, thats 16 LCDs, and    4 sets of buffers, a driver gate for each of D0..D7,RS,RW [10 per LCD].  5 octal buffer/driver would be sufficient in this scenario. The enable lines would be wired 1 to each display so need not be buffered.

 

I'm very serious about building a synth programmer for my Virus's. Ebay has many suppliers of backlit 16x2LCD for <=$3 each including postage!

 

The question is: do I go for 32 encoders (16 chars of display per knob) or 64 (only 8 chars of display per knob).  Or a mixture?

[ilmenator]

Well if you want your programmer to be "larger" than what the original Virus had to offer in terms of knobs and direct access then you want to go 64 knobs, I would think!?

[Duggle]

My latest acquisition is a Virus C (a.k.a.Rack XL), it has:

123 parameters on page "A",   

124 parameters on page "B",

127 parameters on page "C"

 

The Virus B has nearly that many.

 

Almost every parameter on A and B is commonly used in patch design, page C has multi and global parameters (less used).

 

Making the programmer "larger" is impossible! However clever bank design will be important. Question is: is it better to have 64 knobs with terse labels and display feedback, or 32 with very explicit labels and clear feedback? I'm not sure but I've been using my midibox64 now and then over the years and have found the lack of feedback a real problem with it's efficient use.

[Duggle]

I'm now basing it on 4 x Fairlightiii PCB.
 
The encoders are 42.7mm distance from each other. This means that a 2x16 LCD fits above/below a pair of encoders nicely.
 
So each Fairlightiii PCB has 4 LCD's above and below it:

There would be 5 x 4 =20 LCD2x16 modules, however the top and bottom row would be treated as single line (1x16) displays to abide by the RAM limitation.

Would/could NG support this arrangement? (Assuming suitable buffering of LCD bus and distribution of enable lines)

 

It's just that 2x16 LCD's are very cheap (especially in lots of 10).

Here's a diagram detailing how the displays relate to the encoders:

 

[TK.]

I will come back to this topic this weekend. :)

 

Best Regards, Thorsten.

[Duggle]

Very exciting, TK!

If there is any flexibility with the amount of display RAM then that would be welcome. :smile:

>>I take it that the buffering would consist of the LCD output J15 driving a number (say 4) inputs of non-inverting buffer for each signal of the LCD bus?

>>(Assuming the buffer can drive 4 LCD's, thats 16 LCDs, and 4 sets of buffers, a driver gate for each of D0..D7,RS,RW [10 per LCD]. 5 octal buffer/driver would be sufficient in this scenario.

>>The enable lines would be wired 1 to each display so need not be buffered.

Perhaps (?) a more rational way (from a wiring POV) would be to expand on the Core_LPC17 IC2 shift register data inputs. This means having the same serial data feed a number of shift registers simultaneously. This reduces the amount of wiring (by a few wires) but involves the distribution of higher data rate signals which has it's own issues.

[TK.]

Outcome: the usage of serial registers for the additional E lines was indeed the best solution, because the scalability is better than with multiplexers (e.g. a 1-to-16 MUX like the 74HCT4514), which would lead to many variants depending on the number of outputs (e.g. you are planning to use 20 LCDs, accordingly two multiplexers would be required...)

 

This approach also means, that a common MBHP_DOUTX4 can be used to provide the E lines for 32 additional CLCDs

 

Instead of chaining the shift registers with IC2 (which is in the critical timing path - software wise... - it's better to separate data from selection lines), the shift registers have to be connected to J28 of the MBHP_CORE_LPC17 module. This port has already the right pinout.

 

 

I implemented the extension into the app_lcd/universal driver today.

Maximum number of LCDs: 64 (limited by the size of the "display_available" variable only, but it's very unlikely that somebody will add more than 64 LCDs in future...)

Up to 2 MBHP_DOUTX4 modules can be chained at the J28 port to get up to 62 E outputs. The first and second E line are still available at J15A/B

 

 

Configuration: has to be done from the MIOS32 Bootloader Update app, it allows to set the number of LCDs in X and Y direction.

X means, that multiple LCDs can be combined to a single "line" like known from MBSEQ V4 - e.g. it's possible to combine 4 2x20 LCDs to a 2x80 line.

 

 

Test application: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmios32_test%2Fapp_lcd%2Fclcd_multi%2F

It initializes and stimulates all LCDs as specified in the bootloader configuration.

 

 

MBNG hasn't been enhanced yet, but I will do this soon.

In future it will take the "LCD layout parameters" specified in the Bootloader once more than 2 LCDs are specified (means: the user has explicitly changed the configuration)

 

 

Hardware-wise I'm unsure if additional buffers are required for the data lines.

It depends on the capacitive load at the data bus, how many LCD modules can be driven by a single IC2 of the core module.

Fortunately the output data of this shift register can be replicated, e.g. for a group of 8 LCDs - in this case, the serial inputs of IC2 have to be connected in parallel to the additional 74HC595's

 

With such a configuration, the D7 data lines of all LCDs still have to be connected together for the feedback to P1.19, which is used to poll the busy state of the selected LCD.

In order to prevent short circuits between the data output shift registers, it could make sense to add diodes to each "feedback line".

P1.19 has a pull-up during the polling loop, busy=0 is the "active value", which means that the anode should show to P1.19

 

Best Regards, Thorsten.

[MaG2k]

hi T.K.

 

wouldn't that be a nice display for e.g. the LRE8x2 project as a kind of lable display?

 

http://artronic.pl/o_produkcie.php?id=1328?

 

i didn't realized a MBNG Core yet, so please forgive me my dumb question...is it possible to use for example 16 of those 6x1 LCDs as a kind of labledisplay above each encoder and is it possible if the encoder is not be turned that in the display a lable is writen in short (like...CC01, CC02, CC03 or user edited shorts ENV, ATT, SUS, REL, CUT....) and if it is be turned that it shows the value (0-127)???

 

How will that many LCDs be applied to the core???

 

Regards

MaG2k

[TK.]

This is indeed a nice display! How much does it cost?

 

 

 

is it possible to use for example 16 of those 6x1 LCDs 

 

Yes, this requires two chained 74HC595 at J28 for the 14 additional E lines of the LCDs which can't be directly connected to J15A/B

The hardware side will be properly documented once it has been tested by Duggle.
From the software side in V1.011 only 2 CLCDs are supported, but with V1.012 up to 64 CLCDs will be accessible!
There are some other constraints, (see my initial answer), but for 16 6x1 LCDs there won't be any issue.
It could make sense to connect a 2x20 directly to J15A, so that you are able to access the SCS
 

 

as a kind of labledisplay above each encoder and is it possible if the encoder is not be turned that in the display a lable is writen in short (like...CC01, CC02, CC03 or user edited shorts ENV, ATT, SUS, REL, CUT....) and if it is be turned that it shows the value (0-127)???

 

No problem, the messages are fully configurable.
See also: http://www.ucapps.de/midibox_ng_manual_fs.html

E.g. in order to write "ENV  0" ... "ENV127" to the first LCD, write:

EVENT_ENC ... lcd_pos=1:1:1  "ENV%3d"

In order to write this message to the 16th LCD, write:

EVENT_ENC ... lcd_pos=16:1:1  "ENV%3d"

 

Best Regards, Thorsten.

 

[MaG2k]

Hi T.K.

 

some weeks ago i ordered some 20x2 LCDs for me and two of the 6x1 LCDs for a colleague of me. I got them on ebay but the link i posted here is the official polish website of the seller. I searched on ebay today but found that the seller doesnt have any offers on ebay at the moment. i hope that he will make offers next time again. if not i can try to contact him on his polish webform. the displays them self were realy cheap...as i remeber right the were around 2,50€ each. The time they took from poland to me was around 3-4 days. the came certified mail. But i cant say something about how good they are...the colleague of me doesn't have time to check them.

 

about the display-text-topic you wrote...if i understand you correct it is only possible to make the lable fix...it would be nice if the base setting for the encoder lables is the CC that is programmed to them. if the user will change it to a userlable it would be nice to do it also via the menu of the runing MB NG Core. Its a little difficult to discribe what i mean. think on a big audio mixing console like studer, lawo or stagetek...label above every channel strip naming the channel...(in our case the encoder)...automaticly named with CC name and could be changed by user to text of his choice (only change the text but not the function). then it would be nice to have the possibility to save this as a user preset so that you can use the encodermatrix for different midi devices (synths) but always the correct "channelnaming" and function can be restored. Hope it comes a little clearer now.

 

i will have an eye on ebay the next weeks hoping he will offer some of that displays again. the encoder-rows of fairligthiii's design are a little to close together to give an LCD above every encoder. The only possibility is as you showed above "over-under".

 

Regards

Matthias

[TK.]

i hope that he will make offers next time again. if not i can try to contact him on his polish webform. the displays them self were realy cheap...as i remeber right the were around 2,50€ each. The time they took from poland to me was around 3-4 days. the came certified mail.

Wow! I'm definitely interested - please keep us updated! :smile:

 

 

Hope it comes a little clearer now.

 

CCs can already be named "dynamically" by using conditional labels: http://www.ucapps.de/midibox_ng_manual_ngl.html

Only useful if the MIDI Learn function is used, because otherwise you would change the event assignment manually in the .NGC file anyhow.

And such a file can be quickly changed from MIOS Studio - much quicker than on the simple SCS interface.

 

It needs some configuration in the .NGC and .NGL file, and it definitely won't be possible to do this from the SCS! But it's possible - and probably much more flexible than you noticed yet (or know from any other MIDI controller)!

 

Note that multiple .NGC/NGL setups can be stored on SD Card.

So, you could also use different setups for different synths.

More discussions about such conceptional topics please not in this dedicated LCD thread, but in a separate thread.

 

Best Regards, Thorsten.

[TK.]

The Multi-CLCD option is now fully implemented and will be released with V1.012! :smile:

 

As long as "only" 6 CLCDs are used, the E inputs of the 4 additional CLCDs can be directly connected to J28 pins

With more than 6 CLCDs shift register(s) will be required.

Before the official release all the options and the configuration procedure will be documented properly at a new MBNG manual page (currently the only blocking point ;-))

 

Best Regards, Thorsten.

[novski]

Does  TK's implementation of SSD1306 also work with the MB_NG?

 

http://www.ucapps.de/mbhp/mbhp_lcd_ssd1306_multiple_mios32.pdf

 

[TK.]

I haven't tested this yet, but up to 8 SSD1306 based GLCDs should already work with the latest sources which are in the SVN repository.

 

I will add a J28 based CS extension for these displays as well.

 

Best Regards, Thorsten.

[novski]

Hmm... Sounds great! 

What are the limitations with GLCD because of ram? 

 

Thanks TK!

[TK.]

CLCD: 1024 characters

GLCD: 512 characters (because the other half of the buffer stores the used fonts)

/edit: buffer size has been increased, see next topic

 

Best Regards, Thorsten.

[TK.]

With V1.012 the Multi-LCD handling is fully integrated.

The buffer size has been increased (again) to cover multiple GLCD displays.

Documentation: http://www.ucapps.de/midibox_ng_manual_lcd.html

Best Regards, Thorsten.

[John E. Finster]

i would like to put in a feature request for the display of the logic control message.

 

afaik it is 112 characters long and with the ^txt56 syntax the cursor is set to a second line to print the the characters over 2 lines.

 

what i like to request now is the possibiliy to spilt up the message, so that the coulmns of the individual tracks can be placed freely and maybe displayed with individual fonts.

 

i am thinking about splitting the 112 characters of the message into 16 pieces (a: char 1 - 7 ; b: char 8 - 14; c: char 15 - 22; ....).

every piece could now be placed where one desires over the available lcds (e.g. 8 ssd1306 displays, so every track could have its own  :D  ).

 

would this be possible?

 

pardon me, if this is already possible and i just overlooked it.

 

thanks and greets

[TK.]

As mentioned in http://midibox.org/forums/topic/17545-midio128-v3-mehr-dindout-ports-möglich-vergleich-zum-ng/?p=154493'>this (german) thread I will probably use the MAP feature to assign the cursor positions.

 

This isn't implemented yet, but it will be available soon.

 

It will also be possible to define the initial cursor/lcd position, and to define the font in a label attached to the EVENT_RECEIVER.

Background: by using the "small" 3x8 font, this will allow to display the 2x56 message on a 240x64 LCD.

Of course, also the "big" 24x16 font could be used to spread the message over even more screens.

 

So: this will be available as well, and with the latest GLCD changes in V1.013 there is finally no conceptional blocking point for the implementation anymore. :)

 

Best Regards, Thorsten.

[John E. Finster]

Great! I am looking forward to it...

Thanks

[novski]

Is it possible to turn a Display 180° in Software?  :rofl:  ( i made a bad mistake...) 

[TK.]

No problem, I added a the display type 0x85: SSD1306_ROTATED

The change is already in the repository, and will be released with the next MBNG version.

You can use the v1.010 bootloader to select this type (0x85) - it will say "unknown", but the change will be accepted.

 

Note that after changing the display type and uploading the MBNG update it will be required to power-cycle the core, otherwise the GLCD won't be initialized correctly (it has to be reset...)

 

Best Regards, Thorsten.

[TK.]

Now available in v1.015 together with the cursor map and GLCD font changing feature for ^txt and ^txt56 SysEx commands

 

Best Regards, Thorsten.