On Fri, 16 Nov 2007 12:08:43 -0500 Frank Pirrone <frankpirrone@xxxxxxxxx> wrote: > Mark Constable wrote: > > On 2007-11-16 03:03 pm, Frank Pirrone wrote: > > > >>> SO........ 20GB storage, 4TB/mo. bandwidth > >>> > > > > Storage is not an issue but bandwidth always is. > > > > > >> This is absolutely NOT the way to construct a song through on-line > >> collaboration. See my postings for an alternative detailed proposal. > >> They generated little comment, so I assume little interest, but this > >> magnitude of traffic and bandwidth is both whacked and needless. > >> > > > > I totally agree. There are at least 3 levels of involvement, > > > > a) anything light and simple to initially define a song, proof > > of concept songs only have to be MIDI tracks, using say the > > fluidr2 soundfont, along with live medium-fi vorbis tracks > > > > anyone gets to play on this level, even via 56k dialup from > > Nigeria (ooh, bad example) > > > > b) a semi-pro final mix using flac'd 16bit/44.1khtz audio > > tracks and as many MIDI tracks that can be rendered to 16/44 > > locally (without requiring any transfer of large wavs) > > > > a bit of a compromise but I'm sure the end result could be > > quite satisfactory, and so so much Better Than Nothing > > > > c) if a song, or piece, passes both the previous levels and is > > deemed worthy of super-pro mastering then those intimately > > involved with the piece can make their own arrangments to > > deal with transferring 32bit/96khtz master tracks to wherever > > is going to do the final mix(s) and perhaps use archive.org > > to hold the complete final master mix components > > > > I'd be impressed if I ever see a LAU based a) let alone a b). > > > > A c) by the end of the decade would be too cool. > > > > And just as a note, I am personally interested in GPL-like > > songs where the components that went into making the song are > > also available somewhere, hence the idea of using Subversion > > to deal with some, or even all, parts of a song and indeed it's > > entire life cycle of evolvement can be logged and this creative > > outline or path is ALSO of great interest to me. A bunch of > > guys using collab in "secret" and suddenly releasing a final > > mastered ogg to listen to is of little interest to me. How a > > song is created with access to the digital parts that make it > > up is what I find the most exciting part of this discussion. > > > > Oh, and actually listening to something, as well, would be > > kinda cool too :-) > > > > --markc > > _______________________________________________ > > > Marc and the Band! > > I think we're generally on the same track, but I feel even the MIDI base > of composition is a needless complication. A low-resolution OGG > aligning and registering with the base track would be both uploadable > and downloadable by that postulated Nigerian. > > Again, my suggestion entails: > > * simple FTP access to a modest server > * everything is rendered as OGG and synchronizes automatically > * only downloads are new tracks, and only if desired > * only uploads are contributors new tracks > * even mixing and mastering can be done on the compressed files > * high-res files are only required for final rendering > > > Storage capacity can be as low as 100 megabytes or so for twenty 5MB > compressed tracks, and bandwidth might be as little as 5 megabytes when > a single transfer is underway. Assuming 10 participants in different > timezones it may never be higher than that. If we "assign" down and up > times we can even control that, though this is NOT my recommendation. > > Frank I've been keeping out of this up to now, as I've been very unsure exactly what people are proposing, and the complexity involved. However this last suggestions looks like something I would be able to work with (always assuming I can find some spare time!) -- Will J Godfrey http://www.musically.me.uk _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
