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

[Jonas Smedegaard]

-----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 ;-)


>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

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.


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



>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

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

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


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

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.

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