Label Value Source & LED Labels: New in MDP2 2.180

Question

Also... in this version we also added show-hide panels reacting to Extra CC & Hold:

Show Hide Panels

https://mididesigner.com/qa/8537/show-hide-panels-with-buttons-in-midi-designer-pro-2-150

Extra CC & Hold

https://mididesigner.com/qa/7/extra-cc-and-hold

Answer 1

I tried a sample conversion of the Jupiter Xm read tones page.  It gives a much cleaner view than using the pickers for display

But ---

This is particular page is prolly not deployable.  The picker allows arbitrary length.  The standard label runs out of display between 14-18 char (depending on width).  For this example, I divided the decode into four sub controls.  But, there are 6622 entries per control.  The prior decode page was 3.6 Mb (4 tones, drum is only 91 items).  The new version comes in at 9.3 Mb, pretty steep price for a single page.  This is no complaint on the upgrade, just against my poor choice of a first example.

Images

Image 1

Comments

Maybe led font is useless and a fixed width font would be better

Though led font would solve too

---

Not a font problem.  I guess I never thought about it, but the fixed width in the pickers is good.  I believe there are times where the LED will be killer.

My problem is the size of the database of 6682 tones to decode.  The raw data is ~ 1/3 Mb, repeated for four controls.  

I am digging around now to find a better example to code.

---

We're worried about... file size on disk? Are we sure it's a problem... in memory? In load times? Etc.?

There are several solutions on our side for this, including shared ticks, better compression, etc. None of which are currently implemented, of course...

Not sure about the LED font and its usefulness. My first feeling is "dig in further" and allow for LED fonts for the entire layout, and all labels under controls etc. My second feeling is "reverse course" and go with a fixed-width font for labels instead.

---

Just seems non-optimum to have one single page account for more than 1/2 of total program size.  Two additional examples below.

---

Hmmm maybe there are some simple optimizations I can do for storage size

Answer 2

I tried a sample conversion of the Jupiter Xm read tones page.  It gives a much cleaner view than using the pickers for display

But ---

This is particular page is prolly not deployable.  The picker allows arbitrary length.  The standard label runs out of display between 14-18 char (depending on width).  For this example, I divided the decode into four sub controls.  But, there are 6622 entries per control.  The prior decode page was 3.6 Mb (4 tones, drum is only 91 items).  The new version comes in at 9.3 Mb, pretty steep price for a single page.  This is no complaint on the upgrade, just against my poor choice of a first example.

Images

Image 1

Answer 3

Another example, maybe more subtle. The RD-2000 has a large matrix of controls, what value is assigned to control, and in what zones. This update makes that display a little cleaner (still a lot of information).

Left is existing with the horizontal slider kludge to display a single text line, right is updated with the dynamic label (plus cleaning up the text to fit)

Images

Image 1

Answer 4

Another example, maybe more subtle. The RD-2000 has a large matrix of controls, what value is assigned to control, and in what zones. This update makes that display a little cleaner (still a lot of information).

Left is existing with the horizontal slider kludge to display a single text line, right is updated with the dynamic label (plus cleaning up the text to fit)

Images

Image 1

Answer 5

Another demo of 2.175 - combining show/hide and dynamic labels to change color of the label text. 

Pseudo level display, where orange is too low, white is ok, yellow caution, red overload.

Answer 6

Another demo of 2.175 - combining show/hide and dynamic labels to change color of the label text. 

Pseudo level display, where orange is too low, white is ok, yellow caution, red overload.