align-toparrow-leftarrow-rightbackbellblockcalendarcamerachatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-crosscrosseditemptyheartfacebookfullheartglobegoogleimagesinstagramlocation-pinmagnifying-glassmailmoremuplabelShape 3 + Rectangle 1outlookpersonplusImported LayersImported LayersImported Layersshieldstartwitteryahoo

representing/generating multitrack audio projects

From: Stephen H.
Sent on: Saturday, January 19, 2008 1:55 PM
Sorry for the long mail...kinda got carried away with this.. I am  
wondering if there's been any activity in managing collaborative music  
projects with version control.

seems like project files (ableton .als, cubase .cpr, garage band are  
the ones i've checked) are slightly readable at best. i'm guessing the  
merge process would be best approached with an audio/visual preview  
environment, and that would need to be done individually by ableton,  
steinberg, apple etc. for their multitrack editors. do any of them  
offer this sort of thing?

maybe in the upcoming ruby audio library discussions we could talk  
about a way of providing a more readable file format for representing  
and working with multitrack audio that might be more conducive to svn  
based version control than the existing proprietary formats. svn could  
handle the binary audio sources as well as the more readable text  
project representation.  I'm sure a richer merging environment than a  
text editor would still be neccessary for resolving conflicts, but  
maybe this would be a useful approach.  also might be a quick way for  
building multitrack project scaffolding programmatically. maybe  
something like

kick_drum_source =­'kick.aif')
kick_drum_delay =­w(:time =>  
500.milliseconds, :feedback => 0.9)
kick_drum_reverb = => 0.2)
kick_drum = (­ kick_drum_reverb).to­ kick_drum_delay
# chuck style
# kick_drum_source => kick_drum_delay => kick_drum_reverb
# would be preferable if possible

snare_drum_source =­'snare.aif')
snare_drum_fx1 = SuperJetFlangeForeve­rDonkeyWorld(:brocco­li =>  
12, :arp => :moof)
snare_drum_fx2 = MoreJetFlangeForYou(­:hello =>[masked])
snare_drum =­ [snare_drum_fx1, snare_drum_fx2]

song =
song.duration = 1.minute

song.create_track :kick_drum_track do |t|

song.create_track :snare_drum_track do |t|
   t.event(snare_drum, 0.seconds, 1.5.seconds, :decay =>  
50.milliseconds).rep­eat_every(8.seconds,­ :offset => 1.second) do |time|
     time < rand(song.duration)

# song.render() or something similar makes the following json file  
which would be readable by the visual multitrack editor

   'instruments': {
	  'kick_drum_source': ['SoundFilePlayer', 'kick.aif'],
	  'kick_drum_delay': ['DelayWithFeedback'­, {'time': 500, 'feedback':  
	  'kick_drum_reverb': ['Reverb', {'mix' : 0.2}]
	  'kick_drum': ['Compose', ['kick_drum_source',­ 'kick_drum_delay',  
   'tracks': {
     'kick_drum_track' : [
       ['kick_drum', 0],
       ['kick_drum', 2000],
       ['kick_drum', 4000],
     'snare_drum_track' : [
       ['snare_drum_envelop­ed', 1000],
       ['snare_drum_envelop­ed', 9000],
       ['snare_drum_envelop­ed', 17000],
       ['snare_drum_envelop­ed', 25000],
       ['snare_drum_envelop­ed', 41000],

i'm not sure if this would be too restrictive (i also forgot to deal  
with volume, track fx, envelopes, automation, etc.) but maybe these  
would be useful for building scaffolding for projects and representing  
them...i.e. use the ruby to generate the base json file, and then  
allow further edits to happen with respect to that so that the initial  
bootstrap file would be editable months into the project, but the user  
could still make non-programmatic deletions and additions in the  
visual editor that would lie on top of the generated scaffolding.

would definitely appreciate feedback on this


Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy