bongo-devel
[Top][All Lists]
Advanced

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

Re: [bongo-devel] Re: Bongo marking and selecting random tracks


From: Daniel Brockman
Subject: Re: [bongo-devel] Re: Bongo marking and selecting random tracks
Date: Mon, 02 Apr 2007 00:16:07 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.92 (gnu/linux)

address@hidden (Daniel Jensen) writes:

> Daniel Brockman <address@hidden> writes:
>
>> address@hidden (Daniel Jensen) writes:
>>
>>> 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.
>
> Okay. I'm still having problems thinking about it.

On second thought, it is a really bad idea.  It's actually
so bad that it embarrasses me that I suggested it.

The intra-playlist queue should work as expected, of course,
even in random playback mode.  That is, enqueuing a track
should cause it to be played next (overriding the random pick).

What's more, the intra-playlist queue would normally unwind
as the tracks are played: when all intra-playlist queued
tracks have been played, the queue will be gone.  I don't
think this is how Anthony wants his feature to work.

So I withdraw this suggestion. :-)

>>> 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.
>
> Ah, but I meant the imaginary feature I described above,
> not the sectioning/collapsing.

Oh, okay.  Now I understand that paragraph.

Yeah, that's what I meant by `play masks'.

>>> 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.
>
> Ah. I didn't know. But I guess this is not a feature,
> rather an accident of implementation?

Hmm.  I pretty much designed things to work like this from
the start, so I can't really say it's an `accident', but I
have to say it doesn't look like a feature the way it works.

It is probably more useful to pause all other playlists when
starting or resuming playback than to let multiple playlists
play stuff at the same time.

There should be a customization toggle for this.

> On second thought, maybe it might be an idea to not change it.
> I'm sure somebody can think of a way to use this behaviour.

Yeah... using specialized backends, I can think of a few
ways to use this.  Like, playback on different machines?

>> What would it mean for a playlist to be `active'?
>
> I mean that there would be only one playlist at a time.
> Maybe as a minor mode?

Okay.  Yeah, it would work.  Do you think that would
be better than pausing other playlists automatically?

I don't particularly like the idea.  It just seems like a
potentially annoying limitation.

> Yeah, you're right that this is probably what
> `bongo-prefer-library-buffers' is for. I'll have
> to think more about how it's not exactly the same.

It's an interesting and complex subject.

-- 
Daniel Brockman <address@hidden>




reply via email to

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