addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1launch-new-window--smalllight-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [electronicmusic-152] representing/generating multitrack audio projects

From: star m.
Sent on: Saturday, January 19, 2008 3:04 PM
addendum to that:

http://hans.fugal...­  -- 99% complete Ruby implementation of
the OpenSoundCOntrol protocol

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: http://electronic...­
> To unsubscribe or to update your mailing list settings, click here: http://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


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