Subject: [linux-audio-user] The Open Loop Library, a few questions
From: Darren Landrum (consul_AT_studioconsul.net)
Date: Fri Dec 20 2002 - 07:06:05 EET
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. ;)
This archive was generated by hypermail 2b28 : Fri Dec 20 2002 - 07:06:15 EET