It’s not an easy task what you tried to achieve. I also failed my first attempt … but it will be done sooner or later, i’m pretty sure!! 
Next time i will try with the SSD1306 OLED display. I think it’s the best bet …
Regards,
This thread seemed to peter out! I have a 1.8" TFT LCD Color Display Module SPI ST7735S working with Zynthian which has a resolution of 128 x 160. Adjusting the font allows list content to (mostly) be seen okay but rotary parameter graphic does not render well. I would say that such a low resolution undermines the effectiveness of Zynthian. It will work but is a bit irksome. There may be something we can do to optimise for smaller screens but it might not be worth it! (Maybe use a different representation of value of parameters if the resolution is detected to be below a certain threshold.) I am going to purchase a larger screen and am just toying between 3.5", 5" and 7". I quite like the idea of a large capacitive touchscreen for X-Y performance (but not in the cold without special gloves 
) but have read in another thread that it may prove challenging for mounting, connecting, etc. (I bought a Kedei (read crap) screen for this project which was a mistake - I am getting quite a collection of useless screens!) I do have some 128 x 64 OLED screens but wouldn’t think it worth the effort trying to get X server running on these.
3 Likes
Ohhhh that is awesome though! Thanks for sharing all this. Yeah probably needs a different ui for such low res screens. I was imagining just rising filled rectangles in each corner, like any old level meter I guess. Or stack the parameters a bit and have horizontal rectangles inverse the background and text. Of course, I don’t have the skillset for that, and I imagine it would take a lot time for a basically never-requested feature hehe. That is getting into Organelle/Ornament & Crime/Terminal Tedium territory for jamming a lot into a tiny OLED. Id imagine many folks would prefer a sequencer on the Zynthian with a bigger screen
1 Like
Hi @riban !
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!! 
Thanks a lot!
2 Likes
…and some audio . . . 
2 Likes
I’ve got a small 1U rackmount network device. 5V and lots of LEDs. I am interested having low res as well.
1 Like
If this chat had audio I’d ask to turn it off
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).
2 Likes
Layers:
Note that 8pt font renders poorly but is legible. Smaller fonts are too difficult to read.
Synth control:
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.
2 Likes
Maybe different sizes for the different parts.
Intelligence won’t be intelligent enough to cover all options.
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).
1 Like
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?
1 Like
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.
Hi Rockwater!
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:
self.plot_value=self.plot_value_arc
self.erase_value=self.erase_value_arc
by:
self.plot_value=self.plot_value_rectangle
self.erase_value=self.erase_value_rectangle
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
Regards,
2 Likes
Ask Apple and look at the fun they had with a watch…
There is a damn good reason if, in clock making slang, everything on the watch face beyond hours and minutes is called COMPLICATION
1 Like
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").
3 Likes
On my little sketch (if it matters) I didn’t think to specify all auto-scrolling of names would be horizontal, left to right.