hi - based on this, you might be interested in the SAOL project for
musical description.

https://sound.medi...­

from the page:

"Structured Audio means transmitting sound by describing it rather than
compressing it."

from a brief review of the content, it looks like a xml-style
description of *all* of the elements of a composition that is then
compressed in to an mpeg4 stream.  i'm sure that's and overly simplistic
definition, but there ya are :)  

https://sound.medi...­

OpenSoundControl might also be a solution that meets at least part of
your description of the problem - arbitrary values (including binary
content (samples, patches, etc?)) and has a larger existing following in
existing audio applications.

OSC examples:
-- original OSC homepage
https://archive.cn...­ 
-- OSC introduction 
https://opensoundc...­
-- OSC sequencer 
https://iannix.la-...­ 
-- Abelton Live OSC API
https://opensoundc...­

should be pretty trivial to create an OSC to XML translator.  there are
probably already projects out there for this (i plan on researching this
more myself)

aside from that, most source control systems will allow check-in of
arbitrary files, so maybe just having compositions and assets checked in
at various checkpoints would be a simple way of solving the version
control problem.  patching/merging in the source sense would still be an
issue, but that's i guess what you are looking to solve with the
descriptor files.

hope that helps at all - 

star 

On Sat,[masked] at 16:55 -0500, Stephen Handley wrote:
> 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 = SoundFilePlayer.new(­'kick.aif')
> kick_drum_delay = DelayWithFeedback.ne­w(:time =>  
> 500.milliseconds, :feedback => 0.9)
> kick_drum_reverb = Reverb.new(:mix => 0.2)
> kick_drum = (kick_drum_source.to­ 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 = SoundFilePlayer.new(­'snare.aif')
> snare_drum_fx1 = SuperJetFlangeForeve­rDonkeyWorld(:brocco­li =>  
> 12, :arp => :moof)
> snare_drum_fx2 = MoreJetFlangeForYou(­:hello =>[masked])
> snare_drum = snare_drum_source.to­ [snare_drum_fx1, snare_drum_fx2]
> 
> song = Multitrack.new
> song.duration = 1.minute
> 
> song.create_track :kick_drum_track do |t|
>    t.event(kick_drum).r­epeat_every(2.second­s)
> end
> 
> 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)
>    end
> end
> 
> song.play()
> 
> 
> # 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':  
> 0.9}]
> 	  'kick_drum_reverb': ['Reverb', {'mix' : 0.2}]
> 	  'kick_drum': ['Compose', ['kick_drum_source',­ 'kick_drum_delay',  
> '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
> 
> stephen
> 
> 
> 
> 
> 
> --
> Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
> This message was sent by Stephen Handley ([address removed]) from Bay Area Computer Music Technology Group.
> To learn more about Stephen Handley, visit his/her member profile: https://electronic...­
> To unsubscribe or to update your mailing list settings, click here: https://www.meetup...­
> 
> Meetup.com Customer Service: [address removed]
> 632 Broadway New York NY 10012 USA
> 
-- 
Mechanize something idiosyncratic.
--------------------­--------------
cell  :[masked]
yahoo : the_shift8
aim   : og_shift8