14 Nov
2007
14 Nov
'07
3:49 a.m.
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