Subject: Re: [linux-audio-dev] "pro" soundfile editors for linux
From: Paul Winkler (slinkp23_AT_yahoo.com)
Date: ti helmi 08 2000 - 01:46:01 EST
Jörn Nettingsmeier wrote:
> i do hope this is a joke
no, but maybe unreasonable, and quite possibly a waste of your time.
But I'm enjoying it. :)
First of all, pbd has already announced that his file-naming scheme
will be for all intents and purposes unlimited. so I'm happy.
Let me say also that I'm not a track-hungry lunatic. Most of my
recording experience has been done on 4-track cassette with
occasional forays into pro studios (up to 48 tracks on our latest
album and yes we used 'em all up for a song or two.)
Yes, 1000 tracks seems like an unusually high number to me, but not
inconceivable. 26 takes per track does not seem high at all. There
are documented Beatles sessions where they got over 100 (mostly
incomplete) takes *on tape* before they decided they had it.
I can't imagine *using* 1000 tracks in a final mix but I can
definitely imagine putting stuff on 1000 tracks at some point while
working on a song.
My point is that when technology evolves to a level that a previous
limitation (which once seemed like more than enough) disappears,
there is an opportunity for totally new work methods to evolve. This
is good. The whole point is that we don't *know* what someone could
/ would do with >1000 tracks. Maybe 999 of them get thrown out
eventually. The final result might not necessarily sound like a lot
of tracks. To me, the whole point of digitizing information is to
remove familiar physical-world limitations and see what happens.
> if not, read on:
> open and flexible design is one thing, but if it means that the file
> counter has to be long long int, something is going haywire.
OK, so, thinking practically for a minute... :)
so let's say it's a plain old unsigned int. If I remember right
that's 65535 possible files on a 32-bit machine and something like 2
billion on a 64-bit machine. It's probably not too much to ask that
someone who "really needs" more than 65k track-takes per song should
fork up for a 64-bit machine. :) I was more thinking about the
file-naming scheme: I think it should not have a built-in limit,
especially not a 26-take limit. pbd is removing this limitation, I
have no more complaint there.
Here's one possibly-silly, possibly-not way to use tracks >999:
What if I wanted to group my tracks so that tracks 0-99 are always
used for vocals, tracks 100-199 are always used for acoustic
instruments, tracks 200-299 are always used for ambient mics, etc
etc? makes it a bit easier to keep track of your stuff if you
develop a system...
> i guess this "someday, maybe we'll need..."-attitude is
> counterproductive for two reasons:
> first, i had the impression that it ate up a lot of time during the
> initial planning stage of mucos or whatever it's called now.
I think this is a very good thing. I think this is exactly why mucos
will supercede every plugin API to date.
> second, i wouldn't for my life want to listen to music produced on
> more than 48 tracks.
I bet you do, more often than you think, and I bet you like some of
it. The modular digital multitrack has made it affordable for
studios to get really crazy with the number of tracks.
> ok, this is my personal opinion, but i doubt
> that any sane musician will ever use > 999 tracks, and the insane
> ones use windows anyway.
no no no, that's the point: the insane musicians are the people who
do really interesting things! Invent a crazy tool and sooner or
later a crazy person will come up with a really cool use for it.
> and since it's all free software, things can easily be expanded if
> the basic design is solid. getting this app to handle 10000 tracks
> looks like one typedef and a couple #defines.
OK, you got me there. I like to complain more than I like to look at
C. :)
-- ................ paul winkler .................. slinkP arts: music, sound, illustration, design, etc. A member of ARMS -----> http://www.reacharms.com or http://www.mp3.com/arms or http://www.amp3.net/arms personal page ----> http://www.ulster.net/~abigoo
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST