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

[Eben Eliason]

On Thu, Dec 18, 2008 at 12:45 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.  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).

> 3) Add/remove/rearrange playlist, except currently active song

I don't think this actually brings much benefit, given the added complexity.

> 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.

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.

> 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.


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.

But in general, I'm really excited about what you've got so far, and I
don't think anyone disagrees that having a default media player that
isn't Browse would be awesome.  Having any form of collaboration on
top of that will be fantastic.

- Eben


> Technically I imagine 1) best done by multicasting a stream, and each
> peer getting info on the stream URL.
>
> Personally I have (with MPD and some ugly hacks) used a combination of
> 1), 2) and 3) for small private parties I have thrown in last couple of
> years: Multiple pools of amp+speakers with 1), and a few consoles with
> 2) to allow all party-goers to collaborate on selecting music, while a
> single DJ is "king" and can reject or reorder such requests queueing up.
> When the DJ goes home (or gets too drunk) then access is switched to 3)
> to let anyone be semi-DJ without breaking a song already started.
>
> (no, to be honest my setup switched to 4) when the DJ "stepped down from
> the throne" - which caused frequent interruptions by inexperienced and
> drunk semi-DJs, ruining the dance floor).
>
>
> The ability to do 1) is important: The classic setup with few
> loudspeakers means that the sound level in the room (expecially when
> standing close to them) is too loud to chat. Many smaller loudspeakers
> spread out keeps the general volume down.
>
>
>  - 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)
>
> iEYEARECAAYFAklKjD0ACgkQn7DbMsAkQLgN7ACfd62dpv3ddSc4FGo/hkwTOZiG
> XRcAnjnL2MwXESsiNSKGOD4IBmpwYzU8
> =ccxh
> -----END PGP SIGNATURE-----
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>