I’m really interested in making zynthian work in tiny displays like the one you used. Please, could you share the detailed instructions for configuration, etc.?
Also, send some photos!!! I’m really curious of seen your u-zynthian!!
Unfortunately, whilst playing with other displays I seem to have broken the ability to connect to this one (and indeed run Zynthian at all). I am flashing a new image and will retest this but the following are the notes I made when I did it (based on advice from Daniel Müllner):
Enable 1.6" TFT as /dev/fb1 in landscape with pins on left:
TFT Pin
RPi Pin
RPi Header
VCC
3.3V
17
GND
GND
25
CS
CE0
24
RESET
GPIO25
22
A0
GPIO24
18
SDA
MOSI
19
SCK
SCLK
23
LED
GPIO12
32
/boot/config.txt:
dtparam=spi=on
/etc/modules-load.d/raspberrypi.conf:
spi_bcm2835
fbtft_device
/etc/modprobe.d/fbtft.conf:
options fbtft_device name=sainsmart18 rotate=90
/etc/rc.local
gpio -g mode 12 pwm
gpio -g pwm 12 900
Web interface: Hardware->Display:
Display: Custom device
Config:
Width: 160
Height: 128
Framebuffer: /dev/fb1
Web interface: Interface->UI Options:
Font size: 8
Font Family: Helvetica
Enable cursor
Note: GPIO 12 is used to drive LED but should configure this using backlight driver. (I haven’t figured that out yet.)
Note: Enable cursor because I don’t have encoders working yet and this is not a touchscreen.
This little colour display is 35mm tall so would fit neatly in a 1U case. When I have it running again I will add some photos.
My Zynthian is currently a load of jumpers and breadboard on my desk so not the uZynth or anything I can play yet (for wyleu’s obligatory rite-of-passage demo).
Note that parameter name obscures parameter value image. Maybe we could limit (truncate?) parameter names for low resolution screens. This could be an issue for any screen so maybe there should be some form of intelligent adjustment of on screen elements based on screen real estate (resolution).
So it isn’t too bad but could look nicer. As a rough and ready interface it kinda works.
There is now an overlay for the SSD1306 OLED display so it should be possible to get one of those working. I don’t have any that aren’t in use so I can’t test this… but I would suggest that these are too low resolution to be of much use. Three 1.8" 160x128 display is tight so a 64 pixel tall display may prove a challenge too far . We could design different display and workflow for very low resolution screens and we could equally add features for larger higher resolution screens. I’m not sure either is desirable (yet).
Looks like an idea! Would need custom widgets which would be a fun side project for someone with time on their hands . Where is Google’s Summer of Code when you need it?
Hmm or maybe just an underline showing approximate value, and using 3 digit number for exact - if we are down to ascii only oled instead of graphical. “If someone would just code my amazing ideas” hahaha dont we all wish.
Your layout is quite interesting …
The auto-scrolling text is not currently implemented in Zynthian-UI, although it should. In the other hand ,the “bar-level” indicator is already implemented and can be enabled by simply changing 2 lines in the code, in “zyngui/zynthian_gui_controller.py”, line 91, replace:
The text labels are positioned out of the rectangle, so it should be changed too. Anyway, it’s not a complex task, but quite tricky!! Designing a responsible UI is more tricky when display is smaller
Course if we could render it as a D3 svg we could do Browser desktop icons too …
The thing you learn from driving the display smaller is what is critical information and what is advisory . . . and it takes a long time to get it write ( Android I’m looking at you and your tiny, often unreadable clock)
We have recently gained a status bar and I would be REALLY like that to render meaningfully, even if it’s just a set of coloured pixels!
So we get into the area of subtle hints, trying to convey meaning with visual tags. .
In some ways the considerable number of engines and presets we provide can be a problem because you are crossing the divide from what should be in a select list for quick selection on a small display, with a lot of scrolling required to find the strings.
We cater for this well with snapshots but really you want a search facility that can extend right across the engines. We divide nicely here between gui and webconf and would recommend that programming up a zynth is a webconf job and selecting live a gui mission.
Because we prioritise by engine we loose the ability to compare A PureData string implementation with the finest that fluidsynth string can offer, and that’s might conceptually remove a large amount of structural stuff we expect the user to understand.
Having used the µZynth for a few days I can report that such a small screen is uncomfortable to use.
The font needs to be so small to fit much on the screen that even with my reading glasses and a magnifying glass I struggle to see some elements of the display.
Fitting less on screen leads to more scrolling which make for a less fun experience.
Status area is almost useless. The minimal approach leads to tiny elements that are indistinguishable from each other.
Positioning of rotary encoders to allow comfortable control means they are not aligned with the screen and extend the vertical space required, reducing the advantage of the small screen. Having smaller (than 20mm) knobs may reduce this impact but may also reduce the ease of adjustment. (Small knobs on rotary encoders do not work very well.)
Parameter control is obscured by multi-line labels.
Top bar has insufficient vertical space to display scrolling scrolling and status info
So my assessment is that a 1.8" display is just about usable for a standard Zynth but is sub-optimal. Anything smaller would likely be useless (or extremely limiting). Such a small display may be advantageous for smaller form factor devices but these are likely to be used for performance where a larger display of the current patch is preferable.
My recommendation would be to consider a different UI for such small displays but this can present issues with code maintenance, documentation and user experience. It may be plausible to design a reduced size widget set to resolve some of the overlap issues. I think there should be a performance mode which displays the current patch in larger font which would address some of these issues if the small form factor device is primarily for performance only, i.e. not for sound design.
It may be appropriate to fix some of these issues with alternative display widgets and have a performance mode which is optimised for the display resolution in which case the could be a place for the µZynth but with current implementation I would recommend use of a larger display (than 1.8").
Is the bit at the bottom a representation of each of the value widgets? Is the 3 digits the MIDI controller number? Do you anticipate this being at the outside, i.e. left for the left two widgets and right for the right two widgets?