One of the features currently missing from the onebrowser branch is the
level of support for -mixers- that is available in the trunk. In
particular, the Play-Hold types of action in the ip3k Player-UI and the
SqueezePlay-UI, and the *M* icon in the Web-UI.
The philosophy of onebrowser is such that the data in the -feed-
accepted by the various XMLBrowser implementations should be
UI-neutral. This is not always the case at present, in that some of the
{Album,Artist,Genre,Year,Track}info menu items may contain UI-specific
elements but, in general, this has been eliminated.
The existing API used by mixers does not fit well with this philosophy.
In fact it is a really bad match.
The existing mixer implementation is also possibly more complex than
really necessary, in that it allows multiple mixer-providing
implementations to be active simultaneously.
The only mixer functionality included to any degree with SbS is the
MusicIP plugin. The MusicIP service is, effectively, obsolete and no
longer maintained or supported. Currently, it is still possible to
download the necessary libraries. It has to be questioned whether it
makes sense to continue to provide support for MusicIP, at least as a
built in part of SbS.
It is clear that mixers provide some very interesting functionality. It
also seems clear that, for those that use it, the Play-Hold
functionality is important. We have no real idea how many people use
mixers but one has to think that it is a very small part of the user
population.
There are probably three classes of play-hold functionality:
- from artists, album, track, genre or year while browsing the
library;
- from a now-playing screen or track in a current playlist (I think
this still works, at least for SP and probably never worked for
ip3k);
- from a context-menu item - for example, the "Album" item of a track
context-menu (how useful is this?); note this is not the same as an
item in a context menu that specifically invokes a mixer.
Is there anyone who would be interested in:
- Designing the feed API for XMLBrowser necessary to support mixers
in cross-UI manner, along with any necessary implementation in the
three UI-specific XMLBrowser implementations? I have a simple idea
below.
- Taking ownership of the MusicIP plugin as a third-party plugin and
porting it to the new API above?
I have in mind a basic API:
- An -action- (in the sense of -actions- supported by the XMLBrowser
implementations in onebrowser) would be defined: 'create_mix'.
- This action would be included in the BrowseLibrary results for all
suitable queries (which is probably all of them), if at least one
mixer is in use.
- The SP-UI implementation would map to 'play-hold'; the ip3k
Player-UI implementation to the 'create_mix' function (itself mapped
from play-hold in Default.map; the Web-UI implementation would map to
the *M* icon.
- The command invoked, which would be an XMLBrowser command, would
call the Mixer API in some way. If successful, then the returned
XMLBrowser feed would send the UI (ip3k and SP) to Now Playing,
otherwise it would display an error via a show-briefly. The existing
CLI *mixermenu* command might be a good start.
- The mixer API invoked would not have access to a Slim::Schema
object. It could have access to the id and type of the object. The
mixer plugin would then be responsible for recreating the
Slim::Schema object if needed.
- I guess it would be easy enough to have single- and multiple-mixer
versions of the command but is that really worthwhile?
- It could be that the Mixer API would return an XMLBrowser feed,
instead of just a boolean result, in which case that would allow for
more complex interactions - is this necessary?
- Any UI-specific stuff in existing mixers that would be related to
play-hold functionality would be obsolete.
--
awy
------------------------------------------------------------------------
awy's Profile: http://forums.slimdevices.com/member.php?userid=7480
View this thread: http://forums.slimdevices.com/showthread.php?t=85896
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta
