tomtetobe / remuco

Automatically exported from code.google.com/p/remuco
0 stars 0 forks source link

Generate playlists from nearby client prefferences #20

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
This issue has been migrated from SourceForge.

Title : generate playlists from nearby client prefferences
Origin: https://sourceforge.net/support/tracker.php?aid=2808091

==================================================================

When: 2009-06-18 09:07:43
Who : nobody

Let each individual client create custom playlists (or taglists) and
generate small random playlists based on the devices that are in reach. 

-------------------------------------------------------------

When: 2009-06-18 09:07:43
Who : mondai

Sounds interesting, but I'm not sure what you mean exactly. It would help
if you describe your proposed feature more detailed. An example usage
scenario is useful too.

-------------------------------------------------------------

When: 2009-06-18 15:25:40
Who : divineant

silly me, i forgot i had an account.

The specific purpurse that I have a use for, is a way to control our
"festival camp music box".
Given the degree of alcohol intake in such a place, the goal is to have as
little interaction with the device as possible, which in turn means that
the software has to decide what music to play. But unlike a regular
randomize, i want the generated playlists to reflect the musical
prefferences of the people in the camp.
So, if we have N people in the camp all equipped with a bluetooth enabled
telephone, the server must recognize the individual devices and compare
them with predefined preferences. 
Say each device is associated with 1 genre each, and in a given moment 10
devices are in the camp, then the playlist has to be generated with the
following rules :5/10 Metal, 2/10 Rap and  3/10 Pop. Should one of the
devices leave, or another device enter, the the rules are changed and the
playlist must be regenerated.
Of course this is a simplified example, each device should be able to list
more than one preference each.

I realize that these capabillitys proberbly goes beyond most players, so a
middle layer between the player application and the server is needed to
handle device-prefference bonding.

This feature is intended to function as a fallback if non of the clients
make specific choices through the regular interface, but in order to
function properly the maximum queue size must have a finit size, so one
client can't fill the playlist for the next couple of hours.

To make it even smarter,  a client could rate different genres/tags/tracks
with a value between -5 and 5 . i.e. you like Metal, but you dont like Nu
Metal, except this one song by some band.

The client interface should have a rating interface, that is either
specific to the current playing song (rate: artist, song, genre, associated
tags, etc), or lists of all tags,artists etc in the database
see http://studenterradioen.dk/setpreferences.png for a quick mockup.

I hope the concept is clearer now

-------------------------------------------------------------

When: 2009-06-19 16:27:35
Who : mondai

Ah ok. I think I gout the idea. The very basic idea is a bit similar to a
voting feature (see
http://sourceforge.net/tracker/?func=detail&aid=1764399&group_id=166515&atid=839
318
). In general clients need a special "contributor interface" instead of the
current "control interface". That is they contribute by sending preferences
to the server.

I like your idea. On the other side I'm not able to realize the full
proposed functionality in a short time (Remuco is only a free time
project). Anyway, I think it should be possible to start with a very basic
preference based control - for instance clients could browse a list of
artists or genres and select 5 favorites or so.

Which player do you intend to use in your "festival camp music box"?

-------------------------------------------------------------

When: 2009-06-19 16:29:00
Who : mondai

If you don't mind, could you attach your mockup to this thread? Would be
good for later reference.

-------------------------------------------------------------

When: 2009-06-19 16:56:14
Who : divineant

I cant seem to find an option to attach anything to this thread, since i
was thoughtless enough to create it as an anonymous user. I have opened a
new one on
https://sourceforge.net/tracker/?func=detail&atid=839318&aid=2809144&group_id=16
6515

So just close this one, and well head on to the other one

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Here comes the other one
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

This issue has been migrated from SourceForge.

Title : generate playlists from nearby client preferences
Origin: https://sourceforge.net/support/tracker.php?aid=2809144

==================================================================

When: 2009-06-19 17:11:27
Who : divineant

Let each individual client create custom playlists (or taglists) and
generate small random playlists based on the devices that are in reach. 

The specific purpurse that I have a use for, is a way to control our
"festival camp music box". Given the degree of alcohol intake in such a
place, the goal is to have as little interaction with the device as
possible, which in turn means that the software has to decide what music to
play. But unlike a regular randomize, i want the generated playlists to
reflect the musical preferences of the people in the camp.

So, if we have N people in the camp all equipped with a bluetooth enabled
telephone, the server must recognize the individual devices and compare
them with predefined preferences. Say each device is associated with 1
genre each, and in a given moment 10 devices are in the camp, then the
playlist has to be generated with the following rules :5/10 Metal, 2/10 Rap
and 3/10 Pop. 
Should one of the devices leave, or another device enter, the the rules are
changed and the playlist must be regenerated.
Of course this is a simplified example, each device should be able to list
more than one preference each.

I realize that these capabillitys proberbly goes beyond most players, so a
middle layer between the player application and the server is needed to
handle device-prefference bonding.

This feature is intended to function as a fallback if non of the clients
make specific choices through the regular interface, but in order to
function properly the maximum queue size must have a finit size, so one
client can't fill the playlist for the next couple of hours.

To make it even smarter, a client could rate different genres/tags/tracks
with a value between -5 and 5 . i.e. you like Metal, but you dont like Nu
Metal, except this one song by some band.

The client interface should have a rating interface, that is either
specific to the current playing song (rate: artist, song, genre, associated
tags, etc), or lists of all tags,artists etc in the database. A quick
mockup is attached to this ticket.

==========
This Ticket is a copy of
https://sourceforge.net/tracker/index.php?func=detail&aid=2808091&group_id=16651
5&atid=839318,
with an added mockup.
Since i was to stupid to log in when i created the original, i cant append
the file.
==========

-------------------------------------------------------------

When: 2009-06-19 17:11:27
Who : divineant

I intend to use mpd, due to the large varity of frontends, remuco being the
finishing touch.

Actually, when i stumpled upon this application i was in the process of
designing a similar one. But as I have yet to reach a friendly relationship
with j2me, I will look deeper into the actual middle layer, and leave the
client to more capable minds.
Also it should be noted that i havn't actually tried out remuco, other than
getting it running without errors, since my own phone is incapable of
running java. But that should change very soon.

===============
Message from original thread by Mondai
===============
Ah ok. I think I gout the idea. The very basic idea is a bit similar to a
voting feature (see
http://sourceforge.net/tracker/?func=detail&aid=1764399&group_id=166515&atid=839
318
). In general clients need a special "contributor interface" instead of the
current "control interface". That is they contribute by sending preferences
to the server.

I like your idea. On the other side I'm not able to realize the full
proposed functionality in a short time (Remuco is only a free time
project). Anyway, I think it should be possible to start with a very basic
preference based control - for instance clients could browse a list of
artists or genres and select 5 favorites or so.

Which player do you intend to use in your "festival camp music box"?

-------------------------------------------------------------

When: 2009-06-19 17:32:55
Who : mondai

You can use an emulator for testing - see
http://remuco.sourceforge.net/index.php/Client_Customization for some
instructions. This is especially useful to test the use case of having
multiple clients running simultaneously.

Conceptually it is quite easy to extend the Remuco player adapter API (see
doc/api.html in the remuco tarball) to be the middle layer you look for. I
think of adding a method like handle_client_preferences(..). The
implementation of this method would care about interpretation and
combination of preferences and then control the player's playlist accordingly.

Original issue reported on code.google.com by obensonne@googlemail.com on 5 Sep 2009 at 10:48

GoogleCodeExporter commented 8 years ago
Mockup migrated from original issue at SourceForge.

Original comment by obensonne@googlemail.com on 5 Sep 2009 at 10:50

Attachments:

GoogleCodeExporter commented 8 years ago
Related to issue #22.

Original comment by obensonne@googlemail.com on 5 Sep 2009 at 11:03

GoogleCodeExporter commented 8 years ago

Original comment by obensonne@googlemail.com on 22 Oct 2009 at 9:53