Mopidy client with Vacuum Fluorescent Display

Hello,

First, I would like to say that I am quite impressed with the entire project, the design, the code, its extensibility, etc. In this vein, I would like to add some kind of client/extension that does the following:

  • listen to some entity to get the current state, and if applicable get notified on metadata or tag information, track duration and elapsed time on whatever is currently playing,
  • display this information appropriately on a Noritake-Itron Vacuum Fluorescent Display connected to a RaspberryPI4 (device driver on GitHub - PeterWurmsdobler/noritake: Noritake Display Driver).

As for the first part, I have read some documentation on the architecture, the APIs of various components (or actors). But I do not quite know where to start with the listening part, as it appears information could be gathered from various parts. What is the recommendation, and would there be a good example I could replicate?

Any help and hints most appreciated.
Cheers, peter.

I think this Pimoroni extension might do a similar thing to what you want to do.

Hello @jjok , thanks a lot for the link; this is about what I was looking for.

Just a small but important question: how would I get hold of information on performer or composer, aka albumartist and artist, respectively, for classical music? One reason among others I intend to move to Mopidy is that I have the impression that would be a better basis for classical music.

Of course, the question remains: how does Mopidy obtain the tags for performer or composer? I would hope that if could at least extract them from VORBIS comments if my music collection is made up of flac files?

Kind regards, peter.

@jjok , another small question: if a class inherits from mopidy.core.CoreListener and implements event handlers such as track_playback_started, in which context are they being executed? In some thread context of the mopidy core? Consequently, if I want to pass data into an object running a different thread, I would need some thread-safe queue?
Cheers, peter.

Thanks again @jjok , based on the link you shared and Extension development — Mopidy 3.1.1 documentation I was able to make the first version of mopidy client and VFD controller:
GitHub - PeterWurmsdobler/mopidy-vfd

Since I am on Ubuntu 16.04 I could not yet run mopidy successfully to test all, Gstreamer bindings not working for python3.7, but will install it on a RaspberryPi soon.

Regards, peter

Looks like you got the composer information you wanted.
Did you find an answer to your threading questions? I don’t really know anything about threads in Python, sorry.

Hello @jjok , provided that the composer is set in the track information, all should be fine. The only question for me is now how can I make sure that the meta information is indeed retrieved and put into the track structure. That I can only answer once I get modipy to work with my local flac collection; see related thread https://discourse.mopidy.com/t/problem-scanning-local-flac-files/.

Talking of threads, at the moment, as I am still learning about modipy, I assume that extension code such as core-listeners is executed in the core thread context, .e.g. the on_start method or all event handlers such as track_playback_started. To be on the safe side, I have the latter put the data into a thread-safe queue and consume it in a different thread.

That being said, the question is anyway to what extend multi-threading is real in a python programme; I have not much experience here either. I used to use QThreads for a while which has a very neat concept of thread affinity and thread-safe object passing between objects.

Cheers, peter.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.