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..\\\