bongo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bongo-devel] Bongo in Emacs 23


From: Daniel Brockman
Subject: Re: [bongo-devel] Bongo in Emacs 23
Date: Sun, 04 Mar 2007 13:29:02 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.92 (gnu/linux)

Romain Francoise <address@hidden> writes:

> What's the status of this?  Do we have all needed
> copyright assignments?

Yes, although --- like Daniel Jensen --- I have not yet
received any confirmation from the FSF.

> Is the manual an absolute prerequisite?

For development repository installation, I wouldn't think so,
but at least for the release we really should have something.

I haven't put any more work into it, but I would really like us
to get started writing it.  Feel free to start working on it.

Just so you don't think I'm holding out on you, here is the
stuff I wrote before.  Please consider it very much a draft,
please don't hesitate to criticise or change any aspect of it.


   Buffers
   =======
   
   Bongo stores your media libraries and playlists in buffers, and the
   usual way to interact with Bongo is through these buffers.  This is what
   we mean when we say that Bongo is buffer-oriented.
   
   Being buffer-oriented is not unusual for an Emacs application---indeed,
   it is the way most Emacs applications work.  The reason why we make a
   point of it is that EMMS 1, a predecessor to Bongo, stored its playlist
   in a vector and was not oriented around buffers at all.  This did not
   scale well and in fact was the reason why EMMS 2 and Bongo came to be.
   
   As previously hinted, there are two kinds of Bongo buffers: playlist
   buffers and library buffers.  The difference will be explained shortly.
   
   Bongo buffers may contain any arbitrary text, but the interesting thing
   about them is that they can contain tracks and sections of tracks (and
   sections of sections).  Tracks are special lines whose appearance is
   controlled by Bongo.  Most tracks correspond to the name of a local
   media file or the URL of a media stream, but there are other kinds of
   tracks as well.
   
   While track lines have special significance to Bongo, they are really
   nothing more than lines of text with some special properties on them.
   As such, track lines may be killed and yanked freely, both within a
   single buffer and between different Bongo buffers.
   
   For example, you could have one Bongo buffer that contained tracks for
   all your media files, and another that contained the ones you are
   currently interesting in playing.  Then you could copy tracks from the
   former buffer into the latter buffer when you wanted to play something,
   and delete tracks from the latter buffer as you grew tired of them.
   
   This usage pattern is actually so common that Bongo comes with tools
   that make it easy to do exactly this sort of thing.  These tools are
   centered around the concept of library buffers, which are used to insert
   tracks into playlist buffers (from which tracks may actually be played).
   
   Some people who use Bongo never use library buffers, but almost everyone
   uses playlist buffers.  Therefore --- since playlist buffers are more
   important than library buffers --- we will cover playlist buffers first.
   
   
   Playlist buffers
   ----------------
   
   The fundamental concept of Bongo is that of the playlist buffer.
   Essentially, a playlist buffer is a buffer that can play tracks.
   
   In Bongo, all normal media playback is done through a playlist buffer.
   Of course, you may have multiple playlist buffers, in which case you may
   play multiple things simultaneously, but one thing you cannot do is play
   multiple things at once through the same playlist buffer.
   
   It is possible to use Bongo without playlist buffers entirely, but this
   mode of use will not be explored here.  For more information, see [...].
   
   Playlist buffers usually have a current track.  In particular, whenever
   a track is being played, that track is the current track.  When playback
   stops, the current track becomes the last played track; but as soon as
   playback of another tracks starts, that track becomes current instead.
   In addition, there are commands that change which track is current while
   nothing is playing.  Brand new playlist buffers have no current track.
   Killing the current track also results in a playlist buffer that has no
   current track.  However, yanking the track back restores its status as
   the current track (unless another track was made current in between).
   
   When Bongo is told to start playback (and nothing is playing already),
   it will start playing the current track.  If there is no current track,
   it will try to do what you mean and maybe play the first or last track,
   depending on the playback mode in effect.  Similarily, when Bongo is
   told to play the next track, it will play the track after the current.
   
   
   `C-c C-s'
        Start or stop playback.
   
   `RET'
        Play the track at point.
   
   `C-c C-n'
        Play the next track.
   
   `C-c C-p'
        Play the previous track.
   
   `C-c C-r'
        Play a random track.
   
   `C-c C-a'
        Play the current track.  If it is already playing, play it from
        the start.  (Just as `C-a' goes to the start of the current line,
        so `C-c C-a' goes to the start of the current track.)



> Will the Last.fm support go in, too?  (It's a non-free service.)

I don't know what the general opinion about Last.fm is among
free software advocates.  For example, I don't know what RMS
would think about it.

On the one hand, the Last.fm software is freely available
under the GPL and all the user-contributed wiki content is
freely available under the GFDL.

On the other hand, the user-generated data is restricted to
non-commercial use (CC-NC-SA).  I'm not even sure that they
let you download the entire database as one tarball.

Are there any similar services which exhibit a friendlier
attitude towards software freedom?

-- 
Daniel Brockman <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]