You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sure it's cool to have stream sources from users via icecast, but it would be even better to have a nectarine-style radio, controllable directly from the website.
first, things I DONT want:
Too much social engineering or moderation. Vote-up and Vote-down are OK maybe but I don't want to do like "rate 1-5 stars" and start ranking and showing too many stats. It should feel more even, more like going into a record store than a streaming service.
avoid preferential treatment
not too many "magic numbers" like timeout durations, limits, etc.
avoid "keeping score" for anything.
File repo with dubious/incomplete metadata. I would rather have 2 separate types of radio content: one with "official" uploaded and registered stuff, and the other can be an ad-hoc youtube link dump. Both could be in queue, but i'm not going to add a youtube link to the db in hopes that someone adds metadata.
components
the interface
physical, natural, in the 7jam style. no nectarine-style pages and forms.
a room item like a jukebox that you can interact with
only persistent users would be able to contribute
adding songs, editing metadata
Q: permissions. does everyone have ability to edit metadata? tempted to start with "yes", but reserve a way to restrict in the future. needs thought though. probably your account needs to be "associated" with a group/artist/radiostation, given a role of viewer/editor/admin
queueing songs, voting songs?
database / file storage
not possible to do this using our current db methods (just JSON, and forget about mongo). there will be an abstraction so json could be used for testing, but not really worth it: just use mysql on windows. mysql seems the obvious choice.
uberspace provides up to 50gb storage; it's not bad and probably worth just keeping everything together, there.
the radio playlist
for queueing, several have mentioned wanting to be able to queue up pretty much anything. like youtube URLs, soundcloud, etc. this suggests still less control over source audio, a very "ad-hoc" type of thing. This follows in the footsteps of discord music bots and stuff. Nectarine is only more complex because of its size.
the player
really if the db & file store are available, the player itself will not be a problem. the current POC pretty much covers it.
metadata: i believe OGG streams can embed title & artist and other metadata into the stream, but MP3 streams behave differently and only support title. actually in metadata dict it's song but exposed as title. didn't find the exact code which makes this translation but anyway need to remember this
audio stream: i will need to understand this better to know how to make it behave. do i reconnect for every song? does the given example of using a piped file work properly and not feed the entire thing in a burst? or do i need to like, internally mix the audio and provide a "seamless" stream of audio? using the given example i think it doesn't behave well or have good performance characteristics to play well with 7jam which is also running on the server.
The text was updated successfully, but these errors were encountered:
continuation of #230
sure it's cool to have stream sources from users via icecast, but it would be even better to have a nectarine-style radio, controllable directly from the website.
first, things I DONT want:
components
the interface
physical, natural, in the 7jam style. no nectarine-style pages and forms.
database / file storage
not possible to do this using our current db methods (just JSON, and forget about mongo). there will be an abstraction so json could be used for testing, but not really worth it: just use mysql on windows. mysql seems the obvious choice.
uberspace provides up to 50gb storage; it's not bad and probably worth just keeping everything together, there.
the radio playlist
the player
really if the db & file store are available, the player itself will not be a problem. the current POC pretty much covers it.
song
but exposed astitle
. didn't find the exact code which makes this translation but anyway need to remember thisThe text was updated successfully, but these errors were encountered: