I already mentioned the headless client i am developing in the Announcement thread for the beetslocal extension.
Now i would like to ramble a bit about the project to get some new insights, hear about available options, discuss alternative routes or at least to structure my thought and development process.
Firstly, what is it good for?
If you feel at times starting up a client, browsing and searching for music is just to inconvenient.
If you feel existing random play solutions are to simplistic.
If you do not (want to) sit always in front of a screen when listening to music.
If you feel different moods call for different music.
If you don’t want to hear the same stuff over and over again.
If you wish for a learning system to automagically play the right music at the right time.
Maybe the headless client is something for you.
Or maybe my requirements are very special.
After using various Interfaces to operate my music systems, i found the good old remote control to be the most convenient option for me. The X10 Medion RF Remote Control is quite cheap and can be operated through a (thin) wall. I have a couple of these distributed at convenient places ( At the entrance, at the kitchen table, next to the bed etc…) I have a Set of Speakers in every room. They are operated by a central mopidy server. When leaving the house, a single button stops the playback in all rooms. On returning home a single button resumes playback, but i might be in a different mood so the type of music should change.
Some of this is quite simple, other aspects are becoming more complicated.
Secondly, design principles:
Ease of use is key.
Less buttons more intelligence in the background.
Based around “more of this” and “Skip that” requests.
Low system requirements. (Should run on an ARM Plattform)
Features an Implementation:
LIRC and irexec for translating button presses to actions.
For every button on the remote there is a corresponding shell skript in the bin path.
This makes it easy to adapt a buttons action.
Basic Operations
- play
- pause
- stop
- next (skip)
- previous
- jump forward
- jump back
are handled via calls to mpc.
Using mopidys mpd interface.
The more advanced Actions are handled via http requests using curl.
-
play random track (out of a selection defined by a query construct.)
example:
curl --data ‘{“query”: {u"artist": [u"Super Flu"]},“uris”: [“spotify:”,“beetsloca:l”],“options”: {“track”: 5,“album”: 0}}’ http://192.168.0.2:6688/randomplay/ -
play random album (out of a selection defined by a query construct.)
curl --data ‘{“query”: {u"artist": [u"Solomun"]},“options”: {“track”: 0,“album”: 1}}’ http://192.168.0.2:6688/randomplay/
-
play more_by_(album|artist|genre)
-
find related artists on LastFM
todo
-
toggle continous random play (radio mode)
In continous mode, when less then 2 tracks remain to be played, play more by (genre|artist|album} or related artist is called. Continous Mode is a state that is stored in SQLite table.
-
like a track
Every like request increases the rating up to 5 stars. (single button action compatible to usual 5 star rating). A liked track and its rating is written to a SQLite table.
-
track info (spoken)
On request the current tracks attributes are spoken. (todo)
Internal Operations
-
maintain play count
On track_play_back_started play count and last_played is written to SQLite table.
Works for all backends and all clients. -
register skips, maintain skip count
**work in progress
-
rating, play count, last_played and skip count define likelihood for choosing a track
todo
-
save remaining tracklist and play on mopidy restart
todo
Current Status
Proof of concept is operational.
Some small features have a big impact on real live usage, while others have surprisingly little effect.
Despite all still existing shortcomings its quite a pleasant experience already.
