Track Flow Control Dependent on Track Insertion Time

[martindale]

Currently, controlling the order of tracks (say, to follow the currently playing track with another that provides a smooth transition) is controlled first by the number of votes (+1, 0, or -1), while ties are resolved by preferring the track that has been waiting to play for the longest amount of time.

Opening this issue so alternative methods can be proposed.

[zkent]

What about using "reputation" points similar to the way the stackexchange network uses them? Participating in the room earns the user reputation points. For instance, in the sorting example, a user might need 5 points to be able to upvote/downvote a song once. With 25 points, a user might be able to rearrange songs freely within a point range (songs with the same order of precedence). With 50 points, a user might be able to skip a song or delete it from the queue completely. Obviously these are contrived examples but they get the point across. -- Doofenshmirtz

[zkent]

As I understand this feature, this is merely flow control but doesn't really tally any "like"/"lame" votes, correct? Is there a feature planned to track the room's like/lame of a particular song?

[martindale]

@zkent like/lame at playtime, or upvote/downvote of queued tracks? The two mean distinct things, and I'm cautious of conflating the two actions into one (voting).

This issue is specifically about controlling the queue, so that a heavy-hitting track is less likely to play after a softer track. One such solution might be to allow tracks to be inserted as replies to other tracks, allowing voting to control their order so long as they follow their parent track.

[zbeekman]

I agree that those are two distinct ideas: queue votes and likes/lames of a played song. After all, part of what's great about the old TTFM/plug.dj model is that you get to hear new music, so the playlist is not completely beholden to the tyranny of the majority. I think it would be cool to be able to get a score from the listeners about the actual song, not whether it is appropriate to play at the moment. This score could contribute to reputation points, or help break ties in the up next queue. It might also be a good idea to use a low pass filter to come up with this score for a song: you don't want a nearly empty room to make a song have a bad reputation because of a few displeased listeners (say at 4 am) but you also don't want a song that is very popular to be given excessive precedence after it gets played out. Incorporating an IIR/FIR low pass filter like a butterworth filter or similar could also help with this issue. If people tire of it over time it's score will decrease.

In general though, I like that the queue can't be monopolized, and that ties go to the older song in the queue.

[unusualbob]

Its possible this could apply only to machine-played tracks as well

On Mon, Mar 31, 2014 at 6:16 PM, Izaak Beekman [email protected]:

I agree that those are two distinct ideas: queue votes and likes/lames of
a played song. After all, part of what's great about the old TTFM/plug.djmodel is that you get to hear new music, so the playlist is not completely
beholden to the tyranny of the majority. I think it would be cool to be
able to get a score from the listeners about the actual song, not whether
it is appropriate to play at the moment. This score could contribute to
reputation points, or help break ties in the up next queue. It might also
be a good idea to use a low pass filter to come up with this score for a
song: you don't want a nearly empty room to make a song have a bad
reputation because of a few displeased listeners (say at 4 am) but you also
don't want a song that is very popular to be given excessive precedence
after it gets played out. Incorporating an IIR/FIR low pass filter like a
butterworth filter or similar could also help with this issue. If people
tire of it over time it's score will decrease .

In general though, I like that the queue can't be monopolized, and that
ties go to the older song in the queue.

Reply to this email directly or view it on GitHubhttps://github.com/martindale/soundtrack.io/issues/77#issuecomment-39149176
.

Rob Riddle