I need to develop something

[Jim of Seattle]

Well, what you've done on the SF Explorer is very cool, a lot of it is similar to what I have planned, except that mine is going to actually contain the reviews in the DB and allow people to enter reviews within the tool, then cut and paste into the board itself. Php isn't going to help me much, and the whole point of the project is to keep my dev skills limber, so I really oughta do it anyway.

But it doesn't look like the reviews are actually parsed out, just linked as big text things.

[Plat]

But it doesn't look like the reviews are actually parsed out, just linked as big text things.

You're right; I didn't do that. It's mostly useful for analyzing score information right now.

If you want to start from scratch, that's cool with me (I understand, I do that all the time for the same reason), but if you're looking for some regexps (for parsing the "archive.txt" file - it's not as easy as it might sound) or other base perl code, the offer still stands.

At any case, I'm happy to see another developer step up to the plate for the SF community.

[JonPorobil]

rumor has it that VALvE (game company) intentionally released HalfLife2 over bittorrent so they could see where it went for some as-of yet unknown reason. Just remember, I have a friend that downloads stuff almost constantly... bittorrent has others like him.

The fact of the matter is that that copy of Half Life 2 was stolen by a hacker who figured out a Valve network password. He then (possibly) added some modifications and distributed it around the 'net, via bittorrent, among other resources. Valve developers postponed the release of the game indefinitely until the hacker was caught. They put an announcement on the HL2 message board, and fans of the game teamed up to catch the fucker.

There's an interesting article about it in, of all places, Playboy.


More on-topic: Jim, I'm all for the idea of a script for the actual site, like the torrent idea. We don't really need an updated lyric archive (in my opinion) now that the lyrics have been segmented in the board itself (though, on the other hand, it'd be neat to search for lyrics by artist... It'd require a lot of manpower to key in the already-existing material).

And as for the review-o-matic... It might be a lark, but the flaws in the idea are pretty glaring. People already have a habit of saying the same sorts of things over and over in their own reviews; a reviewing script would only encourage them to be more flagrant about it. I know I've felt in reviewing sometimes, "Haven't I said this same thing five times already this fight?" I wouldn't even think about it if reviewing were reduced to some relatively mindless clicking.

[Jim of Seattle]

Yeah, I've already discarded that idea, Jon. I was going to do something more along the lines of Plat's Songfight Explorer, but with reviews. Problem is, people will still write reviews in the boards by hand most of the time of course, so there woiuld be this huge manpower drag importing everyone's reviews into the database every week. So now I'm rethinking even that. Say I imported all the reviews in. It would be up to date for exactly one week. Ugh.

Plat, how is all the data stored in your site? If I could get just the data, without the code, that might help a lot.

[drë]

this is probrably out of scope for .net, but if you want a TRUE programing gig... what about:

THE MUSIC ROOM:
an interactive music room(chat room like) where, after login in each user can pick out a virtual instrument, and play it while hearing other users play their virtual instrument as well. each room would only handel a handfull of players, like 1 drumer,2guitars,1keyboard...etc. with the addition of a text/voice chat as well ofcourse.

you will defanatly have some latency problems.. but oh well.
i was thinking of actually developing this myself a while back using flash player and flash communicator server, even had diagrams drawn out and stuff.. but just never really got around to it.

[Jim of Seattle]

Cool idea. I have no idea how to even begin to do something like that. What would the source of the sound be? How would it work?

[j$]

Jim - i think to avoid dragging 'n'dropping, some kind of review table that pre-set the writers to the boxes would cut out all that import problem. Of course people could still write 'by hand' if they wanted, but under the understanding their comments wouldn't be archived?

Dre - when I worked for a recording studios, a london radio station recorded a live jam between three continents, based around Logic (or was it Reason), so it's doable in theory ....

J$

[HeuristicsInc]

re: live collaboration...
it's difficult, because by the time you hear what the other guy's doing, he's doing something else, because of the latency, especially in audio applications. if you use midi transmission over the net, it's not as bad. but then you're stuck with general midi sounds.
one way it could work is if the first guy is the backbone and other people only react to what he's doing - then he has no idea what other people are doing, but you don't have the circular thing doing on.
when i've streamed over the internet there was about 90 seconds delay, going up to the server and back to my desktop.
-bill

ps oh, there are some other things, where a software program can transmit instructions on how to make the sounds with less bandwidth than sending the actual sounds - if everyone uses the same program there's less latency. but it still limits the interplay.

pps i actually did a live stream where i was playing in one channel and some dudes in france were playing in the other. we couldn't hear what the other was doing. it worked ok, but only because we were doing ambient-ish stuff. you can hear it if you want, let me know.

[Jim of Seattle]

What about this: It's a collaborative loop. So the web app actually plays the same few seconds of music over & over. If you want to contribute, you add something to the loop. So you only upload a few seconds' worth of material. Each uploader could only contribute one thing at a time, so if you upload a new track, anything you already submitted drops out. There would also be a maximum number of tracks playing at one time, so say the max was 5 tracks, if someone submits a sixth, then the app drops the oldest one out. Tracks would also automatically expire after a certain amount of time, so it wouldn't always be at the maximum. There could also be a minimum of one track, so whenever anyone logged on, at least SOMEthing would be playing.

[Leaf]

That is a neat idea... especially if you could include the ability to modify tempo and key....

[Jim of Seattle]

That would modify on its own, as people submitted things in new tempos and keys. Maybe people could specify that something they are submitting should replace something already there. But what if someone submitted only a 2-second track to a 5 second loop? Hmmm....

[HeuristicsInc]

interesting idea, jim...
-bill

[Jim of Seattle]

Hey, I've been thinking about this all morning, and I'm starting to get excited about this idea. I don't think I could devlelop it by myself, though. Here's what I'm seeing right now:

The user would see a virtual "stage" on the screen. This is analogous to a stage in a music club. There would be (let's say) 5 "stations" on the stage. Each station could be manned by a user. So once the stage is full, a user has to step down or log off before someone else can come up to the stage to play. There would be a queue of people who would wait their turn to play. When you're on stage, you can do any of a number of things. You can
a) submit a track to the loop. What you submit is added to whatever is already playing, and everyone starts hearing the new loop with your piece added to it
b) adjust levels and panning of existing tracks. Again, your adjustments immediately go out to everyone else
c) remove tracks from unmanned stations (if any)
Any changes made by anyone on stage would affect the resulting loop globally; everyone would hear the same thing at the same time. This would be a public music creation thing only. No muting or adjusting audio for yourself alone.
When someone steps off the stage, the loop they last contributed would remain playing indefinitely. Any track playing by an unmanned station could be removed by anyone on stage if they choose to. Or a user could remove their own loop before stepping down.
Anyone who logs in, whether they are on stage or not, could listen to the resulting audio. This is analagous to being "in the audience".
Every time anyone on stage makes a change to the loop, an event is logged on an event tracker on the page, so people could see what just changed.
There could be a chat window as well where people on stage could talk to each other ("Can we please get rid of that accordion???")
Technically, there would ideally be a downloaded client app that would accept XML data from the server and display the current stage etc., on a local machine. This client app would alse be responsible for accepting the latest loop and playing it back repeatedly. This means that the server could upload a new audio file to the client, and the client could replace one loop with the other with no breaks in playback. Using streaming audio played on Media Player or something would not be able to do that, and the whole "feel" of the thing would be lost, as it would have to pause to download a new file or start a new stream any time something changed. The client app could allow for an currently playing loop to be saved as an audio file on the local machine. (Conceivably, the user could then take that file and use it as a loop in their own creation on a sequencer. People would have to agree before becoming a contributor that anything they submit is fair game for this purpose.)
Ultimately, the site could host multiple stages simultaneously, analagous to a huge music club with a thousand room in it, each containing a stage with five people playing loops.
The bandwidth would be relatively low. The server would combine existing tracks into a single file, compress it, and send it to clients one time. The client app would loop it. Along with that, the server would send XML files containing metadata about the loop, such as who's playing, event logs, etc. The server would store each track in the loop in a cache, so when someone told the server to, say, remove a track, the server would simply re-compile a new file with that track removed and download the new file.

How does this sound?

[Leaf]

A) Like you know way more about this than me.
B) Like a lot of fun, that could be hugely popluar or...
C) we're missing something here, and it would be a convulted, out of sync mess.


The only thing I wonder is... how does everything sync up? Would the host site provide the sound sources? Can people add samples, guitar parts from home etc?

...I like this idea Jim, it's got the makings of something that could allow traditional "non" musicians an opportunity to make music with others... you could have like rookie to advanced rooms... or some such thing.

[Jim of Seattle]

The way I'm envisioning, everything would come from external sources, i.e. sounds from home. The host computer would supply no content at all.

But you're right, the syncing is a problem. Good call. I guess there should be a way for a user to "audition" his sample on his local machine before uploading it. And in auditioning, he could nudge his sample forward or back a bit until it syncs up. Then he would upload it, so everything uploaded would in theory already be synced up. Along with the audio clip, the local machine would send a time offset.

[Mostess]

Jim! Do this! Holy moly that sounds great!

I would love it if audience members could numerically rate how much they're enjoying the loop at any point in time so the tool could flag "greatest hits" moments where some rating threshold is exceeded and store them (or at least store the information to allow them to be recreated later). Or contributors could see how their contribution affected the general feelings (median rating within some time window before and after the change?) of the audience.

But whatever. It's a lovely concept. Hot damned I love the internet.

[Jim of Seattle]

Oh yeah, that's a cool idea. I was thinking that every time someone made a change, the server would archive the current loop, and you could click on a History button which would play each loop from the beginning in order.

I'd be up for writing this, but I'd need help.

[drë]

like your idea jim.. and probrably can help you out.

but my approch to something like this would be more from a
flash player/ communitor server approche. in where the flash communitor server, creates a shared seassion for a group of users, and then it can broadcast/stream objects(ie. pictures,text,sounds,video) to its clients. i found a tutorial in macromedia.com when i was thinking of doing my little music room app, of how to do a shared whiteboard using the technology describe above. where i use to work, i even set up a little app to get introduce into the whole communicator server thing...
here
http://fvs.blaststream.com/comm/index.html

users can log in, chat, talk, and enable webcam on their flash player.

how to physically accomplish this in .net,vb,c# would be a bit more cumbersome i would think.. what would the client be?? an active X dll that gets install and exectued or a exe that the user would need to download and run ?? i use to do Asp, before moving to codfusion, but don't know much about the .net framework.

[Jim of Seattle]

I was thinking it would be an exe that the user would download and run. Once that's done, they wouldn't even have to open a browser to play. Most of what you said in your post was gibberish to me. But the one thing I did read was "streaming", which is unnecessary in my architecture. I think a single downloaded snippet, looped on the client machine only, would be MUCH more efficient and scalable. But hey, if you're interested, I could write the client and you could write the server. We'd only need to define the format of the files getting transferred. I'm thinking meta data would come via XML and audio would be a simple compressed audio file, downloaded when changes happen. However, your talk about chat and everything does give me pause, because it would be much better not to have to hand code features like that.

[slowRodeo]

This sounds really cool. but i would still like to see something for songfight.

something like an upload page that makes sure that all filenames are the same and automates updates everyweek. refreshes the main page so that everything is moved around and we dont have to wait days to see all the new songs. then the only thing to change is the quippy little comments for last weeks fight and new titles then renaming the artwork for next weeks fight. after something like that i would be more interested in this project.

[Eric Y.]

dude most of that stuff already IS automated. but there is a bunch of work the fightmasters do by hand out of love, because people are idiots and can't format e-mail messages as they're instructed (among myriad other reasons)

[drë]

all right Jim, starting to follow your train of though.
question, what type of connection would the client/server use?
- Sockets, and server pushes new data to client [xml, sound files.]
- after login in, client periodically [5sec..10secs..] connects to server to check for new files ??

another project could be adding a danm spell checker to the message board.. god knows i could use one.