The Song Fight Bulletin Board

So, thanks to everyone here, I've come up with this idea for an online jamming application which I'm calling LiveLoops, that lets users collaborate on loops over the internet. Dre is interested in helping me develop it. I've written up a rough draft functional spec for it. It's a few pages long, and is rough, but hopefully you can get the idea. I'd love to get some feedback on it from the Songfight peeps, since you guys are my target audience anyway.

Jim of Seattle wrote:So, thanks to everyone here, I've come up with this idea for an online jamming application which I'm calling LiveLoops, that lets users collaborate on loops over the internet. Dre is interested in helping me develop it. I've written up a rough draft functional spec for it. It's a few pages long, and is rough, but hopefully you can get the idea. I'd love to get some feedback on it from the Songfight peeps, since you guys are my target audience anyway.

What's a ".doc" file? Emacs doesn't know how to parse it.

The latest version of FruityLoops, version 5, comes with a program called "Collab". Check it out, see if you want to steal any of their ideas. Collab is for collaborating via fruityloops, so it's not exactly what you're trying to build here, but I bet they had to do a lot of the same thinking.

yea it's not letting me read the file either... it'll start downloading it... and it'll try opening it in wordpad... and it'll close everything out...

File loads fine for me.

I think it would be useful if you accomodated multiple loop lengths. For example, Player 1 could set up an 8 beat drum loop. Player 2 could lay a 16-beat synth chord progression over that. Player 3 does 32 beats on bass with a fill at the end. Player 4 could add an embellishment to the drum beat, something subtle like 3 beats, and Player 5 could add guitar fills every now and then.

You could make a whole song that way, depending on how long loops can grow to.

How about "freezing" a loop and adding another loop to the end of it? Some sort of playlist functionality so you can build a longer piece. Could be agreed on by the Players in the chat room, with one Player assigned control over managing the playlist-- "ok, now let's add the bridge section". That would allow true collaboration for an actual song.

jb wrote:
How about "freezing" a loop and adding another loop to the end of it? Some sort of playlist functionality so you can build a longer piece. Could be agreed on by the Players in the chat room, with one Player assigned control over managing the playlist-- "ok, now let's add the bridge section". That would allow true collaboration for an actual song.

now THIS is a cool idea...an m3u collaborative loop file?

I like the varying track length idea. Don't like when everything cycles the same length of time.

Cool idea, btw. Why limit it to 5 players? I can see (hear?) many people contributing and perhaps there can also be a role for a "Mixer", or driver, who manipulates parameters that define track prominence, permanence, and the like, roughing out "sections" and influencing the transformations between them. This mixing role could move among the players, or perhaps you become the mixer after you submit a track, then lose it once another player submits.

yeah, thinking about roymond's comments, it would be good to have some way of making the tracks fairly normalized to each other, either actively or passively, or it could be all over the board, which may not be a bad thing in and of itself but it would probably make for a frustrating mix.

OK, now the floodgates open...

Include visual artists in on the game. Allow backgrounds to bubble up like a lava lamp or one of those sound organs with images and paterns controlled by artists working in much that same way. Other animations appear in layers.

Another option - include some live web image capture and manipulation tools so that a "visual player" can grab web images (off news sites, photo sites, whitehouse.gov, etc.) and incorporate them into the canvas in real time. Or bring her own portfolio to use, of course.

joshw wrote: What's a ".doc" file? Emacs doesn't know how to parse it.

It's an MS Word file. There are numerous ways to read them, including installing OpenOffice, which I use. It's free.

roymond wrote:

joshw wrote: What's a ".doc" file? Emacs doesn't know how to parse it.

It's an MS Word file. There are numerous ways to read them, including installing OpenOffice, which I use. It's free.

I was just being snarky Sounds like a cool idea, though!

joshw wrote:

roymond wrote:

joshw wrote: What's a ".doc" file? Emacs doesn't know how to parse it.

It's an MS Word file. There are numerous ways to read them, including installing OpenOffice, which I use. It's free.

I was just being snarky Sounds like a cool idea, though!

You should still use OpenOffice instead
(and I really was hoping there was someone on this planet who didn't know what Word was...)

joshw wrote:
What's a ".doc" file? Emacs doesn't know how to parse it.

maybe you should try vi

c hack wrote:

joshw wrote:
What's a ".doc" file? Emacs doesn't know how to parse it.

maybe you should try vi

I'm a vi(m) addict, actually, but emacs made a joke possible.

Ok, I hereby proclaim that all text editor and M$ discussion for this thread is finished.

jb wrote:File loads fine for me.

I think it would be useful if you accomodated multiple loop lengths. For example, Player 1 could set up an 8 beat drum loop. Player 2 could lay a 16-beat synth chord progression over that. Player 3 does 32 beats on bass with a fill at the end. Player 4 could add an embellishment to the drum beat, something subtle like 3 beats, and Player 5 could add guitar fills every now and then.

You could make a whole song that way, depending on how long loops can grow to.

How about "freezing" a loop and adding another loop to the end of it? Some sort of playlist functionality so you can build a longer piece. Could be agreed on by the Players in the chat room, with one Player assigned control over managing the playlist-- "ok, now let's add the bridge section". That would allow true collaboration for an actual song.

Those are cool ideas. The whole idea of a loop collab tool is that it keeps the latency, bandwidth, etc., down to a dull roar. The longer the loop is, the longer it takes to download, and the less scalable the application will be if there are a lot of simultaneous sessions going on. Plus, having a repeated loop keeps it interactive, rather than it being this thing that gets played and then the app just sits there dully with nothing going on.

Low latency and scalability are also why I kept the number of players to 5, though I suppose 8 or so would be reasonable. Much more than that and I don't think there would be much payoff, since a collaboration of that size is rare in any form. And of course, there's nothing preventing a single Player from combining two instruments and submitting them as a single track.

That said, I don't think it would add much complexity to allow for longer loops, so there's no reason it couldn't do that. The idea of simultaneous multiple length loops seems complicated. What could happen is that someone could submit a long loop, say 32 bars, then someone else could make something 8 bars long, repeat it 4 times locally, then submit that. Once that section was finished, the loop could be saved as the "verse", then the band could agree to move on to the next section. How about that? It would keep it simpler, but still allow for "real song" collaboration.

Or, there could be a "saved" list, where the band could come up with a loop they like, "save" it to a spearate list, then move on, and then later play back all the "saved" loops sequentially.

I like the "mixer" idea. I'd thought of that as well, but for simplicity sake I allowed for manipulation of relative volume levels of a track before it is submitted. Also, with the chat feature, people could say "Hey, your trumpet's too loud", and that Player could fix it then.

I'm greatly worried about the current requirement that audio has to be recorded from an external app, like Audition or something. It seems a little inelegant to require users to record their loops somewhere else. I just don't want to be building a whole audio editing application. some sort of interoperability would be nice, but that seems like a lot of extra work too, considering how many different apps I'd have to be compatible with.

Keep the thoughts coming! Thanks so much for your feedback so far. So, is this something you think you might use?

Heh, "snarky." When did Josh become J$?

I don't really have anything to add to you idea, Jim, but it's cool so far. Good luck with it!

Ack, joshw is a vim user? I need to reassess my opinion of him!

- a fellow vim user


Jim: For truly awesome emergent music, the loops shouldn't even have to have the same measure length. All that should really match between them is tempo. I've done a lot of experimentation with emergent/generative loop-based music for my day job, and I found that for a lot of styles it was really damn cool when the loops *didn't* line up. Which really threw the composer who wrote the loops into conniptions when I played it for him. Heh.

Also, this idea is very much like ResRocket DRGN, a very cool proof-of-concept app which came from a company which made some embarrassingly poor business decisions (like renting the full app out on an hourly basis, "like a music studio"). In DRGN, people could record MIDI riffs and then arrange them on a global timeline, like a multi-user version of Cubase or Logic (or any other block-based sequencer). I actually found it to be quite useful even from a single-user standpoint, too, since it was one of the more intuitive MIDI recording environments I'd ever used.

jb wrote: I think it would be useful if you accomodated multiple loop lengths. For example, Player 1 could set up an 8 beat drum loop. Player 2 could lay a 16-beat synth chord progression over that. Player 3 does 32 beats on bass with a fill at the end. Player 4 could add an embellishment to the drum beat, something subtle like 3 beats, and Player 5 could add guitar fills every now and then.

You could make a whole song that way, depending on how long loops can grow to.

It works for Brian Eno...

I use vi too, although that might not surprise Fluffy.

I'm not totally satisfied with recording the audio in a separate application, but it would introduce another huge complexity to the app, which is probably too much to ask for in version 1

If tracks of shorter length than the loop were allowed, something could be done to vary the loop over time, without increasing the amount of data transferred. e.g., in a 4-bar loop
a drum beat goes for 4 bars
a guitar part goes for 1 bar. the player decides he wants that part to be repeated on bar 1 and on bar 3.
This would save the app data transfer, as otherwise he'd be transferring two bars of silence in a bigger track file. Also, if you just chose to repeat your drum beat on 1-4, you could upload a file 1/4 the size, if it didn't vary throughout the full loop length.

The chat, I think, is completely necessary.

Saving every loop is probably too much storage, yeah

The time-out period should be determined after you figure out how popular the application is. It can be tweaked on-the-fly.

I wouldn't put a lot of effort in animating the displays... this would be cheesier (and more work/transfer) to have "avatars" playing instruments in little animations and stuff, I think. Nobody has suggested that, but I just thought I'd mention it
-bill

Also, by separating the recording from the playing, this could be <a href="http://trikuare.cx/audio/Project/">entirely web-based</a>.

Or it could be done in Flash, which does support recording now.

you should allow for any loop length within the decided range, not just numbers divisible by 2.

right: it wouldn't be possible for jute to participate unless you could throw in a bar of 13 at some point

I was going to allow for any track length within a loop, and the player could offset it as much as he needed, to start in the middle of a loop or something. But I hadn't thought about one track repeating more than once within a loop. That's a good idea and I think totally do-able.

I can see an instance where there's a 4-bar loop and someone gets the idea of having his track repeat every OTHER time, so he would use the chat to say "Hey, let's double the length of the loop so my track can go every other time" and they do.

As for bars of 13 or whatever, none of this is going to be synced up to bars or anything. It's all straight audio, you all know that, right?

The more I'm hearing the more I'm thinking that people are going to want to collab on longer things than just short loops. Makes sense. So, I'm rethinking the "loop history" idea. There should be an abridged loop history, maybe the last 5 changes or something, but then there should be a vault where bands intentionally save loops they like. That way once they're all happy with one, they save it and move on to the next verse or whatever. Maybe saved loops can be brought up later and re-worked on....?

You guys are being SO helpful. This is the best.