[mythtv] Proposed Change to MythMusic

[Roo]

On 11/07/07, Justin Hornsby <justin.hornsby at gmail.com> wrote:
> It's not even as if you *can* use a mouse with mythmusic yet - none of
> those buttons do anything when clicked.
>
> The one thing I think everybody agrees with is that mythmusic needs to
> be improved.  The thing is, I've yet to see any positive input on
> precisely how to improve it.  There's little use saying "oh it needs
> to be more like X with a bit of Y" since not everybody is familiar
> with X or Y.
>
> What we really need are mockups, functional descriptions & the like.
> Anything a developer can really work towards.

+1


> As far as I know there aren't too many existing apps which make it
> easy to deal with large collections of music other than the now
> ubiquitous albumart browser - but then those don't suit people whose
> music collections aren't based entirely around albums.

Rockbox has a nice feature for metadata browsing, it allows the user
to customise the tagnavi.cfg. Admittedly I haven't tried using this
customisation feature (yet) but  is worth looking at. Rockbox has even
less resources (memory, raw mips, display size, buttons etc) than
Mythtv and their users probably have as varied ideas as to what is
"right" as Mythtv users do.

I have two observations to make with regard to browsing music
collections and creating playlists.

A/
There is no universal navigation structure for all types of music
collection for all users. Some users have a huge singles collection,
others have a majority of albums. Others, I imagine, have a collection
that are top/bottom heavy if sorted alphabetically (every album ever
releaed of their favourite artist).

I think the best design would allow the user to configure the browsing
to best suit their collection.

B/
Rockbox allows the user to define the tag navigation menu, it uses a
config file that the users can define the navigation tree, label each
node and specify the filter for each node.

Maybe Mythmusic could adapt this idea for it's tag navigation
(collection browsing) as needed for playlist editing etc. The exact
format of the config file would need to be decided but I guess it
would be something like:

TagNavi.conf - Query Section (Optional)
=======================
If this section is not be present the query strings would be specified
directly in the tree section.

 If present it would allow the user to name and specify a query string
for retrieving data from the the DB.
* The query could be a "raw" sql query, or,
* The query could be an abstracted mythmusic query syntax, asimplified
query syntax would allow the DB Schema to change without breaking
existing query definitions.
* Defined queries will be named to be used later in the tree section


TagNavi.conf - Sort Section (Optional)
================
If this section is not present an alternative method of defining the
sorting would need to be provided.
* Alternatives could be to have a bunch of canned sort order keywords
defined in myth that are recognised in the TagNavi.conf - Tree
section.
* Another option is to roll the sorting into the Query, a la "SELECT
FROM music_table WHERE (query_string) ORDER BY (sort_string)"

If this section is present it would allow the user to define various
sort orderings to be applied to a selection.
* Mythmusic could implement a simple sort order syntax, again this
decouples the DB schema but does limit it's flexibilty.
* Defined sort orders will be named to be used later in the
TagNavi.conf - Tree Section.


TagNavi.conf - Tree Section (The Workhorse)
==========================
This section would be mandatory, it allows the user to define the tree
structure for the UI to render when collection browsing etc.
The user can define a tree that has arbitrary labels where each node
optionally has a query and sort filter specified as well as a
mandatory label. I imagine that hierarchial nodes would apply their
queries hierarchially.
For example

<queries>
  <query label="highly_rated" sql="SELECT ...FROM... WHERE..."/>
  <query label="recently_added" sql="SELECT ...FROM... WHERE..."/>
</queries>

<sorting>
  <sort label="rating_decending" sql="SELECT * FROM
$query_results...GROUP...ORDER"/>
  <sort label="recently_added" sql="SELECT * FROM
$query_results...GROUP...ORDER"/>
</sorting>

<tree>
  <node label="My Group Label">
    <node label="Highly Rated" query="highly_rated" sort="rating_decending"/>
    <node label="Recently Added Songs" query="recently_added" sort="random"/>
  </node>
</tree>



TagNavi.conf - Location
==============
If a tagnavi.conf style config file was used we could install a
default (as included in the source tree) into /usr/local/share/mythv/
and override it with a per user customised file if it exists in
~/.mythtv/. This would protect the users customisations safe from
upgrades.


Tree Caching
========
It is possible to create and cache the tree data when doing the "Scan
for music", I guess this would be more responsive instead of
rebuilding it each time it is used. Although a tree node may be
dynamic (like smart playlists) if the query string or sort order uses
things like "Last Played", "Rating", "Recently Added" or "Play Count"
etc., you wouldn't cache these results as they could change each run.


Attached is the Rockbox tagnavi.config.

> Ok, so say we do away with the music transport buttons & make viewing
> them (on top of the UI, say) optional so that those with mice /
> touchscreens can use them.  That'd be a start.  We'd still need a
> button to make the controls visible/invisible - or maybe a 'kiosk
> mode' where they'd always be visible.  That'd mean we can devote much
> more screen space to the playlist & music tree.

If the transport buttons are removed from the standard layout they
could be displayed for a short time (1-5secs) over the top of the main
window when the user activates them. If the playback is paused, sticky
ffwd or rwd etc maybe the OSD can remain displayed. If the transport
display is semitransparent it might look ok.

I agree, as far as the transport and the other buttons currently used.
An alternative layout selected in mythmusic setup that switches
between two options, mouse/touchscreen compatible on or off.
* When mouse/touch screen compatibility is enabled either:
 - the transport etc buttons are permanently shown (selects the
mouse/touchscreen layout/mini theme)
- a hot spot is enabled, perhaps the top edge of screen, that displays
the transport etc buttons when the cursor is in the area. The
transport display/overlay would be the same as when the remote is
used. (no need for a mini theme)
- a button is displayed, that when pressed displays the transport
buttons. This is similar to the mouse over above, except the button is
not hidden and requires a button press instead of mouse over.

Maybe we don't even need the setup option to select between the two
modes. If you don't use the mouse then the transport buttons don't
need to be displayed for the user to activate them, they just use the
play, pause etc on their remotes. And the transport overlay will be
displayed when an action is selected, and remain displayed while
paused etc.


> Anyway, I've got some ideas I'm going to get down in the form of
> still-frame mockups.  It'll at least be a *start*, and maybe I can tie
> still frames together in video form to give an overall impression of
> how the new stuff will work in context.

I look forward to seeing your mockups and any others that may also be
put forward for that matter.


Anyway these are some less than fully formed ideas, just thought I
would put them out there.


Cheers,

Roo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tagnavi.config
Type: application/octet-stream
Size: 6936 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20070712/7906d602/attachment.obj