On Fri, Jan 28, 2011 at 5:16 AM, Max Kellermann <m...@duempel.org> wrote: > On 2011/01/28 09:52, Sean McNamara <smc...@gmail.com> wrote: >> The only problem is that mpd itself would be completely unaware of >> this external daemon's existence, and as such, would not (could not) >> provide any management service for it (i.e. stopping and starting it, >> or configuring it). If the goal is not to touch the mpd core, then the >> most logical way to ease end-user management of said daemon would be >> to integrate it as a plugin into the most popular mpd clients. They'd >> have to make a separate TCP connection to the playlist workflow >> daemon. > > This is where an idea steps in I had a while ago: > > Problem: mpdscribble should be able to send the "loved song" flag to > last.fm. However mpdscribble itself is a daemon and the user cannot > interact with it. > > Solution: allow mpd clients to communicate with each others over the > mpd protocol:
Very neat. This is something I've been mulling over recently too: how do I add very precise, specific, peculiar user-driven features to mpd without bloating the core? E.g. I want features like "stop at the end of this song" or "I have to leave the house in 25 minutes, so pick just enough random songs to fill that time and start playing" or "fade out and pause, then rewind 5 sec and fade in when I unpause". All of those are just features that I happen to think digital music players ought to offer. I'm perfectly capable of implementing them myself using the Python mpd client library, but then they're locked in their own little universe -- I have to run a different client alongside GMPC or Sonata or whatever. (Or I have to open a command-line window and do it there, but that's conceptually the same thing.) Or I could hack them into GMPC and build my own copy, but what if I decide I'd rather use Sonata? Or I could hack them into mpd as core features for my own use, but of course you would never accept those patches. And rightly so. A dedicated daemon for my goofy mpd features doesn't solve the whole problem though: I still have to convince GMPC, Sonata, and the rest of the world to give me a GUI to my custom daemon. That's not gonna happen. > mpd could support listing the keywords that clients have subscribed > to; so gmpc could hide the heart button when there is no scrobbler. > Each time a new client subscribes or unsubscribes, mpd broadcasts the > "subscription" idle event to all clients. Even better: make it so GUI clients can discover "custom actions" supported by "daemon" clients. E.g. if Greg's-custom-mpd-controller-daemon offers a "fade out and pause" action, then GMPC could have a "fade out and pause" button somewhere in its GUI. It's much harder if the action requires user input (how many minutes until I have to leave the house?), but there are plenty of interesting things that could be done with a "just hit the button to execute the action" interface. Greg ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
