[mythtv] Proposed Change to MythMusic

[Joseph Caputo]

On 7/11/07, Justin Hornsby <justin.hornsby at gmail.com> wrote:

[snip]

> What we really need are mockups, functional descriptions & the like.
> Anything a developer can really work towards.

Definitely!

> 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.
>
> Some have said Amarok is a good model for a music player but last time
> I looked at that it didn't seem at all viable for mythtv - it relies
> on small fonts & cramming a lot of information on screen, and it's
> hardly very remote friendly.  That part is very easy to forget.

I agree -- Amarok, IMHO, has no equal in terms of features, but it
does not present a good 10-ft. UI.  Though, it would be nice to
incorporate things like lyrics lookup or artist info via Wikipedia.
That's for later on... first we need to get the basic UI right.

[snip]

> If we had $1 for everybody who said mythmusic could bear improvement
> we'd have been able to pay a professional to write a whole new music
> plugin already.  What's needed is more constructive input & much more
> detailed suggestions for a solution to the problem.
>
> Have a think about it - how would you change the way we choose tracks
> out of thousands in our collection?
>
> Let's see less of 'mythmusic could be better / mythmusic sucks' & get
> some case studies down if you really want to help.  Out of the legion
> of mythtv users there must be somebody who has had experience working
> on such a thing somewhere at some point.  There's a real opportunity
> here for people to contribute in a big way IMHO.
>
> 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.
>
> An album art gallery view would be very handy, and as far as I know
> that's 'on the to-do list'.
> You could use that for genres, years.. any other classification too -
> all in addition to the existing list / filtered list views.
>
> The improvements to the display model needn't only apply to mythmusic
> either - I've thought about it in the past & implimenting a new
> 'browser' might work well for recordings & videos too.  Let's face it
> if we're going to get new UI classes why not let the rest of the
> project benefit?
>
> 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.
>
> None of this, by the way, will make any bearing on how to play music
> in the background - but I think we can all agree that the methods we
> use to pick music to be played need some attention.

I'm not so good at mockups, but I have a few ideas.  First of all, I
think the "playback" screen in MythMusic (MM) is too cluttered, and
I'm not just referring to the all-but-useless buttons.  I think the
browsing function should be consolidated into a single "playlist
editing/music browsing" function, while the playback screen should be
very minimal -- current track info (artist, album, title, other tag
data, time/time remaining or a progress meter) and maybe a little
"Next up: <next song>" as an afterthought.  I imagine this taking up
approximately the same amount of screen height as it does now in MM.
The rest of the screen height could be a visualization pane.  You
could toggle between:

(A) split track info/visual (what I just described)
(B) full screen visual
     (B.1) w/fixed track info overlay (toggle via INFO?)
     (B.2) w/track info overlay on track change only

In all cases, no need to show Play/Pause/FF/Rew controls, as these are
bound to the remote or keys.  Maybe have MENU bring up a controls menu
or OSD if we really want it.

Browsing and playlist editing become the same thing.  When you enter
this mode, the pane with the visualization in view (A) becomes the
collection browser/playlist editor pane.  Maybe this view would have
an option to toggle visibility of either the browser or the playlist,
or show both in a split view.

One of the drawbacks of the current MM is that when I'm browsing my
collection (via the playback screen) and I want to hear a song, I only
have 2 choices -- I can either play it immediately (thus stopping
playback of any track or playlist I have going) or I can switch to the
playlist editor and add it to my active playlist, but I can't really
control what order it gets added in.  If I play it immediately, it's
not part of my "active" playlist -- I can switch back to the real
active playlist by browsing over to it and starting to play one of its
tracks.

I think that what should happen is that if I am in browsing mode and I
click on a track, I should have 2 choices: "append to playlist" or
"insert as next song in playlist".

That's all I can think of right now... obviously some more thought
would be needed to really nail down how some of the more advanced
"smart" playlist and tag editing features would tie in.
Comments/suggestions?

-JAC