i know design by committee can be horrible but these situations usually utilize
vastly similar yet incompatible formats, so its sort of biting off something
small, i hope.. :)
(1) Peak Files
some of my favorite wav files have 10 metafiles each. peaks generated for peak,
spark, wavelab, soundforge, cubase, ableton live, samplitude, rezound, sweep,
ardour, plus a dir for "Apple Loops" data etc.
it would be great if each time an audio file enters a new app, the user wasnt
greeted with a 30 second burst of disk activity as peak files were generated
yet again..what exactly is needed? here are some thoughts
- average amplitude per time-slice to generate the waveform overview
* what granularity is useful? peak files seem to run a few %
of filesize..
- spectral centroid for comparisonics/freesound style colorization
- annotations (OPML etc)
- timing (tempo, cue points, beat markers)
rather than invent some new arbitrary plaintext (or XML) format, i'm interested
in using OSC (as described at
http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec-examples.html ) to
encapsulate this data, at which point this is simply an exercise in selecting a
schema/namespace...
beside faster load-times (eg one could pregenerate this data before a
performance or composition session via a recursive shell command and 'sox'), a
commonly understood format would enable easier sharing of CC-licensed material
among a variety of users and apps without useful metadata being 'lost in
translation'. additionally web and other interfaces could be developed using
the metadata hints (see archive.org, NI's KORE)
(2) Instruments
compatibility and reuse of sample-based instruments between chionic, specimen,
DSSI samplers, PD samplers, LinuxSampler, and seperation between editor and
engine allowing more highly specialized apps - the 'nix way.
- get rid of arbitrary region / bank / instrument boundaries
which seem derived from MIDI (the amount of times you see 1-16 and 0-127 in
modern software instruments is appalling)
- sample regions pointing to audio files or groups
- grouping (nesting / tags)
- volume / filter / lfo stuff
once again i am thinking OSC could be suited to this..
(3) 'project' components
monolithic binary files still seem to remain the norm, eliminating all hope
of reuse without tedious exporting of settings or components, things like:
- pointers to regions (audio files, control streams, other projects)
- note and controller-data streams
- instrument / filter settings
ive thought about this a bit and am leaning towards using a directory on disk,
with a format for each of the above, which would enable revision tracking via
SVN or darcs.. note/control data will likely be OSC (and MIDI encapsulated in
OSC where necessary), instrument/filter settings would be closely aligned with
what is fed to LADSPA/DSSI modules, and the pointer 'glue' file linking others
and assigning filter and routing data to tracks, channels, regions..\\\
