[linux-audio-user] The Open Loop Library, a few questions

[Darren Landrum]

After some considerable thought as to the best way to organize such a 
library, as well as what a project such as this will do to my free 
time, I have a few ideas and questions to present to the list.

I'll start with the easy one first.

1) What exactly would this library hold? There's no need for this to be 
restricted to loops. It could also contain other "musical raw 
material", such as sample sets and softsynth patches. In that case, 
calling it the Open Loop Library makes little sense. What else do you 
think would work? Open Music Library? Sounds like it's a repository for 
music, not for raw components. The upshot to the Open Loop Library name 
is that the domain openloops.org is available. It also makes a good 
working name for now.

Really, that was the main question, and it brings part of the proposal 
with it. I would like to design and build a web service to act as a 
library for loops, sample sets, and patches. Here are some thought on 
the overall design.

1) The top level hierarchy would be (obviously enough) "Samples", 
"Loops", and "Patches".

2) Below "Samples", the categorization would go something like 
"Keyboards", "Brass", "Woodwinds", "Synth Leads", "Pads", "Strings"... 
Well, you get the idea.

3) Below "Patches", would basically be the same kind of broad 
categories as with samples.

Now, "Loops" is where things get fun. I've been thinking about Mr. 
Knecht's comments on building an elegant organization system, which is 
something that Acid itself apparently lacks. I think an extensive 
metadata system is the best way to accomplish this.

Every loop would have attached to it:

a) Time signature
b) Tempo
c) Key (If applicable. Drum loops, for example, would not need this.)
d) Creator's name
e) Instrument(s) (This one is tricky, since there are so many 
instruments in the world. It would need to be a free-text field, which 
means misspellings could be a problem. Possible solutions?)
f) Loop or one-shot (Not everything meant for a loop-based composition 
program need be an actual loop. Drum fills and cymbal hits come 
immediately to mind.)
g) Style (This one creates some issues, due to how subjective it can 
be.)
h) Comments (A free text field the creator of the loop can use to 
attach whatever additional info they feel it needs.)
i) A million other things I can't think of at the moment. :)

One problem that needs to be solved is how to attach these kinds of 
metadata to a loop. Also, another thing to consider are loop sets.

Thinking about the architecture for the web app itself led me to think 
about how CPAN works, at least from a user perspective. I would set up 
a central index server, which could then redirect clients to the 
appropriate mirror to grab a file when a request is made. This also 
brings up the idea of a client that could be built that would talk to 
the servers from the user's machine. This client could be used to 
maintain the organization of all the loops the user chooses to 
download. This can be thought about after the main system is up and 
running, though.

As for hosting, I have a good lead on a local colo facility. I have 
some other projects I need to host anyway.

I apologize for the long email. Hopefully, this will start the ball 
rolling, and if all goes well, it won't crush me when I try to catch it.

Regards,
Darren Landrum

who is hoping this hair-brained scheme doesn't spawn another mailing 
list. ;)