The Song Fight Bulletin Board

I really wish ResRocket DRGN still existed so I could show you a model of something which worked really damn well for this exact thing. I'd basically just say "Take ResRocket DRGN and make it with audio instead."

So, instead, try to imagine something with the same basic interface layout as CoolEdit Pro (or Audition), except where anyone can create a new track and record into it, and as soon as a recording is made it's sent up to the server and redistributed to everyone. While the user is actively working on that track, only they have access to it, but after they've stopped working on it (by signing out or specifically giving up control), anyone else could take control of the track. There was also a realtime chat interface beneath (actually, the server was just implemented as a MOO which had special rooms which would tell the client to bring up the sequencer and feed it data, so the chat was "for free" and all of the change notify events were just distributed by the MOO and so on; conceptually it could also be done with an IRC bot or similar).

There are plenty of ways to go about architecting this, and if I weren't already way-too-busy with a time-sinkhole I'd totally join in on the programming.

FWIW, if you do go about this, my suggestion would be to do a proof-of-concept using just MIDI to start with (fewer issues to deal with in terms of bandwidth etc.) and using SDL (which supports MIDI) as a platform abstraction layer, so it's not tied to a single platform. Client-server comms could be done using standard HTTP stuff, where occasionally the clients just ask the server for the current song status, then the server spews out an XML document or similar which says which tracks contain which (externally-linked) mid/mp3/wav/etc. files and where they lie on the timeline.

Edits would just be done as normal POST requests, and would be broken down into three basic operations - upload a riff, add a riff instance, remove a riff instance.

i don't use midi, except as a means to connect my keyboard thingies to my sound-making thingies, so that would be way less interesting to me... but make what ya wanna make.
-bill

I'm not going to do Midi as a proof-of-concept, because the whole user experience would be significantly different than it would for audio, plus there's a learning curve for programming Midi-aware code which I would climb, then not need for the real app. So now worries, Bill.

Fluffy, thanks for the advice. Dre is my current collaborator on this project, but I haven't heard from him in a few days, so I'm wondering... Also, my app has to be .Net, so that I can justify doing it at work as a learning project. And there has to be a smart Winforms client, for the same reason.

I really like your idea of allowing people to take and relinquish ownership of tracks, rather than manning specific "stations". I think I'll change it to work that way instead. So someone submits a track, and they are the owner of it, so no one can edit it, but they can relinquish ownership, which makes it fair game for anyone. I'm thinking that for simplicity sake, the best would be to still allow a player to only own one track at a time.

it might be useful to allow people to own more than one track, if there are not many players.
unless, ... if someone quits, their track is relinquished automatically, and you can also relinquish (man that word is hard to type) a track on purpose and then start on a new one. then you could even play this by yourself. and then if someone joined you they could replace any of your currently looping tracks?
i like taking the concepts of traditional instruments out of the stations and abstracting them to "tracks" of unknown composition, but allowing them to be named for identification purposes.
-bill

Well, the "stations" weren't going to be assigned to specific instruments at all, I was just using it as a metaphor, to indicate that at any one time each person was working on a specific track. I suppose the metaphor would still work even with the new ownership idea. Really, the only difference with this new approach is that a player doesn't have to own ANY tracks currently playing. The reason I want to keep it so that a player can only own one track at a time is to keep the interface simple at the client. A player could of course submit a track, relinquish it, submit another, relinquish it, etc., it's just that he couldn't concurrently own two tracks. The only thing "owning" means is that they can edit it and no one else can.

I don't recall if ResRocket allowed one user to work on multiple tracks at a time, but I *think* it did. Not that the ResRocket model needs to be followed precisely or anything; it's just a data point in terms of how these things have been done before, really.

.NET is annoying since that means I'd have no way of using it (nor would a few other Songfighters) but at least it kinda-sorta enforces the MVC development paradigm (badly), so porting it to other platforms shouldn't be too terribly difficult. (Famous last words, I know.)

Yes, please design this with an architecture that speaks with other platforms

So is it because you are working on Macs that .Net won't work for you?

Well, yeah.

MS claims that .NET is portable to every platform, but they conveniently ignore that in order to port it around you'd also need to port all of WinAPI and also some form of VM which is capable of running its bytecode, and that's assuming it's not compiled native. If it's compiled native then it also needs an x86 emulator.