[ardour-dev] MultiTrack recording

[Paul Davis]

On Sun, 2006-03-05 at 23:27 +0000, Chris Goddard wrote:
> Hi All
> 
> I hope this is the right place for this message. If not please advise.
> 
> I'm currently working for a mobile recording company. We are planning a new 
> truck and have got to the 'what do we record onto' question. On our other 
> trucks, and our de-rig (anything you carry into a venue, record, and carry 
> out again !) systems we have predominantly used Pyramix as it has proved very 
> robust for recording up to 64 tracks for extended periods of time. This new 
> truck is to be a more budget conscious build so we are looking at ways of 
> saving costs, Pyramix can prove rather pricey !
> 
> I have been following Ardour for quite some time and like very much the 
> direction it is taking. With this in mind I am quite keen to put together a 
> test system that uses Ardour as a multitrack recorder. The plan would be a 
> capable PC with an RME MADI card (or two if possible).
> 
> Priorities for any multitrack software for us would be stability and track 
> count. After that..........portability of the audio files.........Editing is 
> not a priority at all, just recording.
> 
> My question I suppose is; is Ardour the right choice for this, could it cope, 
> is anybody already asking this much of it, am I barking up the wrong tree ?

maybe you should talk to harrison/GLW consoles. they are currently
strongly suggesting ardour to their clients as the best software
strategy to use with their current and future hardware.

ardour is perfectly capable of doing what you want, and by most people's
experience is significantly more stable and resource friendly that its
competition. several people are already doing what you are talking about
with ardour; they are not totally free of problems from time to time,
but no more and generaly less than with other solutions.

the major limitation right now is that "extended periods of time" is
limited by the maximum possible size of any mono .WAV file, which for
96kHz is not very long at all. we aim to fix this issue in the very near
future.

--p