[EMAIL PROTECTED] (Daniel Jensen) writes: > Daniel Brockman <[EMAIL PROTECTED]> writes: > >> [EMAIL PROTECTED] (Daniel Jensen) writes: >> >>> Or rather, it is a function of the random playback mode, >>> it does not affect anything else. >> >> I think this is actually a problem. If marks select which >> tracks should be played in random playback mode, why should >> they not do the same in other playback modes? > > Yes, this is a valid point. Unfortunately, I think it will be a lot of > work implementing something that works all around. It sounds like a > unmarked-tracks-are-invisible type of feature, I think that is the > closest to Anthony's original feature request. It could be another > type of mark, but as I said I doubt it is necessary. (See below.)
I still think the intra-playlist queue idea is an okay one. > Well, making tracks invisible is not strictly necessary > either ... I use that feature far too seldom. I should make a habit out of using it sporadically just to prevent bit rot. > Since Anthony's feature will probably not be included in Bongo, here > is my advice (pun intended) to Anthony: > > (defadvice bongo-randomly-playable-track-line-p (after random-follows-marks > (&optional point) > activate) > (setq ad-return-value (and ad-return-value > (or (null bongo-marked-track-line-markers) > (bongo-marked-track-line-p point))))) Cool. This should go on EmacsWiki. > Reminder to Daniel: Don't forget to consider the discussion about the > bug (?) with random playback picking the currently playing track. Thanks. >> Because buffers are convenient enough (and more powerful) >> or because overloading process marks would work well? > > Because of the former. I may be basing this mostly on my own usage of > Bongo -- I use library buffers and compose a playlist when I want it. Okay. I do this too. >> With multiple playlist buffers, some interesting questions arise. >> For example, what if you want to use one playlist buffer as a >> library for another. Could a buffer be both a playlist and a >> library at the same time? What about the UI for this? > > Why have multiple playlists? They can't be playing at the same time. Sure they can. This possibility might not be that useful --- in fact, it might even be good if playing in one playlist automatically paused all others --- but it does exist already. > Are you thinking of having one /active/ playlist, and > other buffers can become the active playlist at the user's > request? This sounds good to me. That wasn't exactly what I was thinking, but it is an interesting model. What would it mean for a playlist to be `active'? > So for example, you can open your library and start playback directly > in that buffer. Then you open a fresh playlist buffer and it becomes > the playlist, you insert a few tracks ... and so on. This sounds like the behavior you get if you only use playlist buffers (unset `bongo-prefer-library-buffers'). I was thinking something like this: playlist buffers can play tracks, while library buffers can enqueue tracks into other buffers. Trying to play something in a non-playlist library buffer just enqueues, and trying to enqueue something from a non-library playlist buffer just manipulates the intra-playlist queue. Library playlists would simply have both these features at the same time: trying to play would play and trying to enqueue would enqueue into another buffer. In addition, enqueue commands should probably not enqueue into any library buffers. This feels natural. To be sure, Bongo wouldn't need library buffers --- you can do perfectly well without them. They are there to help the user use Bongo more naturally. They are just tools. I like Perl. I like its philosophy. TIMTOWTDI. Empower the user by providing a good set of tools. Just as Bongo wouldn't need to distinguish between playlist and library buffers, Perl wouldn't need to distinguish between scalar and array variables. These distinctions are superfluous, but they add richness and character and color. I'm rambling, of course. Brainstorming, if you will. -- Daniel Brockman <[EMAIL PROTECTED]> _______________________________________________ bongo-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bongo-devel
