[Sugar-devel] About the default ogg player in sugar

[Eben Eliason]

On Thu, Dec 18, 2008 at 2:16 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, Dec 18, 2008 at 01:19:04PM -0500, Eben Eliason wrote:
>>On Thu, Dec 18, 2008 at 12:45 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>
>>> On Thu, Dec 18, 2008 at 11:04:47AM -0500, Eben Eliason wrote:
>>>>On Thu, Dec 18, 2008 at 2:03 AM, Kushal Das <kushaldas at gmail.com> wrote:
>>>>>  * Collaboration support
>>>>
>>>>Awesome.  I'm curious to hear what you have in mind for
>>>>collaboration. One of my earlier brainstorms on an audio activity —
>>>>DJ — revolved around the idea that anyone could join to hear the
>>>>audio stream (but wouldn't have any control....it would just be like
>>>>tuning to a radio station).
>>>
>>> I imagine several degrees of collaboration, changeable by the owner:
>>>
>>> 1) Listen
>>
>>This is by far the most important, and probably the easiest to do
>>well.  A multi-cast stream seems right.  This alone would be a huge
>>collaboration win.
>>
>>> 2) Add at the end of playlist
>>
>>This is an interesting idea.
>
> Well, the idea for this isn't mine. It is in fact exactly what I'd
> expect from a good old jukebox in the corner of some dusty saloon when I
> throw it a dime and punch in a letter and a number ;-)

True.  Maybe in that regard Jukebox and DJ should be separate
activities.  Thanks for straightening me out; clearly a Jukebox
activity should support this idea in some form.

>>Let me suggest a slight variation on that idea.  Perhaps (again in the
>>"DJ" mindset) listeners could have the ability to request songs.  It
>>might even be the case that there's some clever support for pulling
>>tracks from the requester, if the owner doesn't have it, but maybe not.
>>In any case, though, this sounds like a nice thing to offer, but it
>>does add a lot of UI, since all listeners need a management interface
>>and access to the list of available tracks (unless it's *just* a
>>request mechanism).
>
> Ah, yes.
>
> If I understand you correctly, I experienced something like this at a
> Debconf (Debian conference) in Finland a few years ago: Connect a print
> spool to an mp3 player with some loudspeakers, and announce the IP of
> the print spool. Then all (geeks) can "print" mp3's and they get queued
> up and played in first-come first-serve.
>
> In other words, I suspect the back-end part can be pretty simple (by
> someone able to code such things properly at all, which excludes me).
>
>
>>> 3) Add/remove/rearrange playlist, except currently active song
>>
>>I don't think this actually brings much benefit, given the added
>>complexity.
>
> Hmmm - I really would expect "collaboration" to be two-ways, not just
> one-way distribution of music :-P

I don't actually see this as being less two-way than basic appending
of tracks; just a bit more limited.  Like a real jukebox, you get in
line when you add a track, and you can't reorder.  I'd stick with that
paradigm, I think.

> Sure it is more complex. Best is probably to not reinvent the wheel but
> use MPD (Music Player Daemon) as communication protocol. But IMO the
> benefit is obvious: You should see my (girlfriends) kids having fun when
> I setup MPD in the living room and then later showed them how they could
> remote-control it, switch tunes, change volume and so on, from their own
> rooms (using thin clients, but that is not relevant here). Now THAT is
> collaboration around a jukebox.

Well, again this has to be considered in the one-room and many-room
scenarios.  Perhaps it makes sense to control some master volume or
current track if we're just talking about remote controls for a main
system, but if you have a number of kids in separate rooms
collaborating, this breaks down completely.  They might want different
volumes, and track-select wars could be introduced; this isn't a
problem if the only operation is "append".

>
>>> 4) Full access to playlist, including start/pause/stop
>>
>>Likewise.  I think this could just cause problems.  If the kids aren't
>>in the same room (and therefore can't interact socially, and can't
>>hear each others speakers), then this doesn't add benefit.  On the
>>other hand, if they are in the same room, one of them could just go
>>press play/pause on the other machine anyway.
>
> You see no point in being able to share a ghettoblaster across the
> globe?!?  It is soooo mind blowing - not networked-by-design like chat
> but a transformation of something once analogue and physical.

Well, the same problem as above arises. If those listening aren't in
the same room, how does one manage the playback realistically? It's a
wild idea, and could be a fun experiment, but I don't see it being
truly useful in context, myself.

>>What I would instead envision is the ability for any kid to
>>mute/un-mute their own stream to turn it on or off, but not the
>>ability to pause or control the stream affecting everyone else.
>
> Mute = owner quits the activity

You don't think each user should have control over their own volume?

> Unmute = owner starts activity from journal (i.e. reloads playlist)

Same question.

> Remote-control is ability to _engage_ in the DJing rather than just
> passively listening.

Still, it seems to me that appending to the list is a fair amount of
active engagement (same as any jukebox) without too much complexity.

>>> 5) Full access to playlist + read access to its media files
>>
>>I also question this one, both in terms of simple implementation, and
>>in terms of legality.  I'm not sure it's necessary.
>
> If not legal to distribute, then probably illegal to stream too in some
> jurisdictions.  Off course it is illegal to share unlicensed works - it
> only ever makes sense to consider the tool used with locally produced,
> copyleft or otherwise properly licensed works. Trying to design it to
> not be possible to abuse for illegal purposes means you should not offer
> two-way networking capabilities in the first place!

Perhaps.  I think it will be questioned much more quickly if it's
obviously a "music-sharing" activity, rather than just a "jukebox".
I'm not sure if OLPC can make a file-sharing activity a default media
player, for instance. ;)  (Though I'm certainly not the one to say,
for sure.)

> I imagine 5) as the opposite of your 2a): Instead of pushing suggested
> songs, you offer another DJ to pull wanted songs.
>
>
>>And, in conclusion, I'd want to make sure that sharing the activity is
>>a simple and natural thing to do.  Ideally there wouldn't be different
>>sharing modes, and there likewise wouldn't be a huge number of
>>switches and levers to set in order to control permissions.  Perhaps
>>taking the multicast stream model and extending it with a single
>>checkbox for "allow others to add to the playlist" would be enough.
>>You could even skip this checkbox if they could only make song
>>requests, rather than actually adding to the list.
>
> Hmm. That is sure different from my idea - I would want more
> collaboration.
>
> I agree that 5) is not so relevant compared to the complexity of making
> it (e.g. ensuring that it does not become an "anonymous ftp"-like
> security whole).
>
>
>>But in general, I'm really excited about what you've got so far,
>
> Not me. I am just throwing ideas here.
>
>
> So, to sum up / rephrase:
>
> 0) Local Jukebox
>
> 1) Allow others to listen / extend range with their speakers
>
> 2) Allow requests from local collection
>
> 2.5) Allow requests from peer-transfered file
>
> 2.7) Allow requests from external URL
>
> 3) Remote-control the DJ console, except current song
>
> 4) Remote-control the DJ console, even current song
>
>
> I just threw in 2.7) as a new idea.
>
> I imagine having only 2 collaboration controls: above as a popup
> selection list, and a checkbox to "keep at bay" which, when activated,
> will turn any request into just a suggestion. So that requests for
> tunes, external files or playlist reordganizations just pile up as
> proposals in a list that gets applied if you locally click on them.

AHH! That sounds far too complicated!  I'd propose:

0) Local jukebox (unshared activity)
1) Allow others to listen (default shared activity)
2) Allow others to append tracks (shared activity, plus one checkbox;
this might be checked by default, since it's the "normal" behavior for
a jukebox)

Here point (2) can incorporate any technology from 2.0, 2.5, and 2.7.
If you *really* want to support the remote control idea, I'd say make
it all or nothing (don't differentiate between control of the current
track or not; if you trust those collaborating, then you trust them to
share in complete control).  I'd then say you could change the "one
checkbox" to a popup with 3 simple options:

Allow others to:
   1) Listen (listen to tracks, all control remains with initiator)
   2) Request (append tracks to the jukebox playlist)
   3) Control (full control over playlist and playback controls)

This popup would only be available when the activity is shared, of
course, which means there's still the option (0) for a local jukebox.
This retains most of your use cases, but simplifies them into
relatively straightforward levels of interaction, with simple one-word
descriptions.  Here again, "request" could be the default, with an
option to add or subtract privileges by one step in each direction.
What do you think?

- Eben


> ...to keep interface simple while keeping the developers of this Jukebox
> activity busy for the years to come ;-)
>
>
>  - Jonas
>
> - --
> * Jonas Smedegaard - idealist og Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAklKoacACgkQn7DbMsAkQLhRGwCfWo29OxE539wv6loWNl/wHJ/G
> 3O4AoKAH7zdQx2NDAHKLR8QBRe3zBzJt
> =1Q55
> -----END PGP SIGNATURE-----
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>