On 2007-11-14 17:26, Patrick Shirkey wrote: > > > I always envisioned just having all the tracks out there, and having > > > any contributor able to make a mix (in EDL form) from whichever > > > source tracks he or she likes. Does ardour use a EDL-like system ? Audacity has it's aup format files that could be useful. > > ...hmm, now that I type this out, it seems a little disorganized. > > still, what do we do if a track is dumped out there, and multiple > > instrumentalists want a chance at it? I know Restivo and I will be > > fighting over who gets to play the rhodes parts. :) No reason why anyone can't "fork" the current piece and start a new one from a particular point of the old ones evolvement. > We would need a way to ensure that we don't end up with every single > wavefile that has been contributed to a project included in every > session. This is where a subversion type approach is helpful. All wavs should be flac'd at a minimum and there is no reason why "testing tracks" could not be, say, in q5 vorbis which would expand to 99% the original quality... at least as far as what is uploaded into Subversion... then when there is concensus that a particular track is "the one" then the lucky end user gets to upload the flac'd version of the test track. > Could we provide an app which diffs project files and creates a small > torrent with only the relevant additions? Bingo, I've been looking around for a torrent based server/client system that handles revisions and delta updates but it doesn't exist. T'would be a great project for anyone into deeper coding. I'd go for Git as the revision backend with a C/C++ torrent lib OR perhaps a distributed rsync client/server system. > It could also have an option > to package the complete session in case someone wanted to start a fork. Simple enough to have multiple torrents, a regular one pointing to the whole audio project to date and a mythical one for distributing the delta difference between "HEAD" and any number of previous revisions (ideally). I suspect one way forward is to define a working toolset that all/most users are happy with and then have a set of bash scripts that tease the data from the toolset into a set of files that makes sense to subversion and automatically commits them. Then the reciprical procedure needs to happen when someone updates their svn working copy, another script breaks out the newly checked out parts ready for the toolset to work with. These bridging scripts can't be written until we know what toolset is in use (perhaps even a range of different toolsets). --markc _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
