Build a small display/OLED module

Hello, and thanks for this Amazing project!

Just discovered it searching some FOSS solution to build a Raspberry-based music box, then I landed to Pi MusicBox and finally I played a bit with the basic Mopidy on a clean debian.

This project is awesome.

And I would like to add my figurate two cents.
I would like to build my custom HiFi streamer that sports two/three/four push buttons, a ditigal knob with push feature and a small OLED for status display: current song, volume, dynamic menus, etc…

The idea is However NOT to write a comprehnsive UI for the whole, but only some quick reference accessors in order to skip the web gui from the mobile for repetitive tasks (like skip, volume change, recall last songs, and so…). So basically I don’t need a whole touch-screen color monitor that could be able to run the webfronted (or even Kodi).
In my opinion, a classic retro aluminiuim rack-sized hi-fi streamer should be… minimal and classy :slight_smile:

After playing a bit to familiarize with the Python module system, I discovered the native support for the (at least partial) MPD protocol in Modipy.
I’ve found some projects around to show (but not control) the status of a MPD server on a OLED display.
But I don’t know how far can go the MPD protocol for a better integration with Mopidy.

So I’m trying to understand which high-level architecture is the best to enhance the modularity of the solution.
Basically, I have two solution: a standalone MPD client (written in any technology) that uses Mopidy as server, or as a real Mopidy module (so based on Python).

The features I would like to implement are:

  • a yaml/json/scripting based UI designer to let customers to design its own UI
  • support any screens dimensions (e.g. 128x64, bigger, smaller…)
  • a simulator UI to test the design and interact with it (gtk?)
  • TTF font support
  • animations/scrolling
  • show basic MPD info
  • interact, list and select last played songs / streams
  • volume/selection knob using digital push-like knob + a couple of buttons
  • extendible support for custom menu (e.g. manage device power down, other inputs, audio output settings, etc…)
  • an API to implement low-level driver for the display and buttons/knob

Ideally, the project could be decoupled by either MPD and Mopidy API in order to be free to be reused in many other contextes.
The question is: given the current status and plans for Mopidy, do you think my project is better to be built as a Mopidy module, or as an MPD client instead? (and eventually extend the MPD protocol of Mopidy to extend the features)?


I’d probably go with the MPD protocol since right away you can also use that with mpd and interest a lot more people. There’s also then no assumption that the controller (buttons and screen) need to be running on the same device as mopidy/mpd, which you otherwise might risk with implementing something like a Mopidy frontend.

1 Like

Great, thanks.
I’m working on a small Python Library for MVC support, so generic enough to be used in all contexts where a graphical display should show mixed content/menus.
Then there will be a sample for a Mpd client.

Thanks, L