On 11 Mar 2009, at 12:23, per.odl...@armagedon.se wrote:
Hej,
The playlistcode is kinda static and ain't that feature-rich and lacks
of alot off basic features. Like picking the next song at random
rather
then shuffle the playlistorder.
We have purposely removed the "random playback" feature because we
wanted to promote party shuffle instead. I think there should still be
some way to activate it, even if it's not done by the server itself.
Overall I like the idea of making the choice of the next track more
modular. However I don't think we should fiddle with that on the
server. Instead, it should probably be managed by special clients
using the upcoming feature, "service clients". Service clients are
clients that expose commands to other clients (through the server).
We want to move the party shuffle mechanism, currently server-side, to
a service client too. It could then be richer (e.g. append entire
albums, or related tracks to the current playlist).
Your idea would fit well with this approach, but it would probably
still require some improvements of the server. Currently there is a
playlist_set_next command, but no way to either monitor when the next
track is changed (using a broadcast for instance), nor any
playlist_get_next to check what's coming next. We also risk racing
problem among multiple clients fiddling with the next track. It's also
important to keep in mind latency between the signal that the track is
done playing and any update sent to the server (not to mention if we
have crossfade in the future). But still, it should be feasible once
there is a clear vision of what/how we want to allow that.
Unfortunately, service clients are not merged yet and we shouldn't
make any assumption that it will be before GSoC. So such a project
should be done as a standard client initially, and we should determine
whether it still makes sense to have it in these conditions (other
clients would not be able to talk to it).
So you're welcome to ask more questions, provide a clearer view of
what you want to do (what should be possible, how clients would use
it, what are relevant user scenarios, etc) and browse around the
features I mentioned above to start thinking of implementation ideas.
Thanks for sharing your idea, we look forward to hearing more about it!
--
theefer
--
_______________________________________________
Xmms2-devel mailing list
Xmms2-devel@lists.xmms.se
http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
