[Ardour-Dev] Non-freewheeling export mode in Ardour 3?

[Jörn Nettingsmeier]

On 11/01/2011 12:23 PM, Paul Davis wrote:
> On Tue, Nov 1, 2011 at 7:10 AM, Leigh Dyer<lsd at wootangent.net>  wrote:
>> On 1/11/11 9:58 PM, Fons Adriaensen wrote:
>>>
>>> But what would be the difference with just recording the signals you
>>> want to export on a new track ? In particular if you could request any
>>> track to use a multichannel file format ? The latter seems to be the
>>> thing to ask for.
>>
>> That might be a nice feature to have anyway, but I don't think it's a good
>> alternative for a non-freewheeling export, for various reasons:
>>
>> * it's more complicated to perform, compared to just running an export with
>> a "non-freewheeling" option set
>> * it needlessly adds the export to the session -- if I have a MIDI only
>> session that's a couple of MB in size, I don't really want to be adding
>> 100MB WAV exports to it
>> * there's no control over export file format (bit depth, sample rate, codec,
>> etc.)
>
> the problem (as i realized overnight) is that the computational cost
> of export is essentially unbounded and so its impossible to do this
> with JACK in normal mode. sure, one could say something like "well, it
> works on most machines if you use only a single uncompressed export
> format". that's not very satisfactory, and isn't likely to ever be
> reliably true enough to justify the claim in the first place.
>
> export is fundamentally different to regular streaming via JACK
> because we allow an arbitrary amount of processing to be done with the
> data before it goes to disk *and* in Ardour3, it may actually go to
> disk in multiple formats (multiple files). there's no way to ensure
> that this processing will keep up with realtime JACK. more
> practically, the current code design for export *assumes* that there
> are no realtime constraints on what its doing. adding that would be
> quite hard.

good point - i almost never use resampling or encoding on export, so i 
never thought about that one. but only a subset of the export modes has 
this unbounded computational cost. how about i tick "real-time export", 
and it greys out all the dangerous options (encoding and resampling afaics)?

those who need rt export won't mind this restriction, because if you run 
complicated setups like that, you are not usually in a tight workflow. 
otoh, people who depend on spitting out three different formats at the 
same time will usually run pretty streamlined setups without much 
external fuss.

of course, the ultimate in terms of coolness would be batch processing: 
export in rt to some native format like caf, float32, then take the 
output and encode or resample it in the background, non-rt. but that's 
not high on the list of priorities for me :)



-- 
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net