Is there any way to change the default audio file format from 32 bit to 24 bit , any config file o so?
I´m seeking on config files on USER/library/preferences/ardour5 but i cant find this option.
I want this because mi interface is only 24bit, and I dont want to waste disk space.
Its unconfortable opening the sesion properties any time when create a new proyect.
It wuold be nice if it could be configured by default.
Thanks for your great job.
Ardour is amazing.
Menu: Session / Properties / Media
Sorry I didn’t read your question properly. You want to change the default file format + bit depth so that Ardour would remember the last choice. I think that would be a nice little feature to have. I’m also always changing the file format and bit depth when I create a new session. It’s no big deal, just a couple of mouse clicks, but this is just the kind of thing that computers do easily 
However at the moment you can do this by first creating a template with all the settings, tracks, routing and plugins you want. Then when you create a new session tick the checkbox “Use this template” and select the template from the drop down list. This is quite a handy feature
You probably don’t want to do that. The reason it shows 32 bit is not because the file resolution is 32 bit, but because Ardour converts internally to floating point representation, which slides the 24 bits of resolution across a sliding dynamic scale. It makes the DSP operations work out better (e.g. EQ and reverb) without the programmers having to worry about overflow and dithering issues in the calculation chain.
Ardour converts internally to floating point representationI was initially going to say the same, but actually there's no reason why the initial recording shouldn't be done to 24bit .WAV files. Ardour's processing (faders, plugins etc) is floating point, but during playback it could be converting the 24bit PCM to 32bit float on the fly as it reads the files. I doubt that it's a very expensive conversion in CPU time.
Thanks everyone for the replies. I know the templates workaround, I create my new sessions that way. I dont know in depth how ardour does the 24 to 32 conversion, but it dont seem to be a hard work. On the other hand less in out work is required to read 24bit files from disk instead 32 bit.
The goal is that if I have a stupid day and I forget to load template, i waste disk space unnecesary.
But I can live whit that, ardour is wonderfull.
Sorry for mi poor english, i do what I can.
On the other hand less in out work is required to read 24bit files from disk instead 32 bit.
Probably not. Modern computers (say for the last 30-40 years or so) would expect the sample data to have the address aligned at least on a 32 bit boundary, so for 24 bit data the file would either have the data padded out to 32 bits so it was easier to read in, or if the sample data was stored in packed format (actually stored as 24 bit values instead of padded to 32 bit values) the data would have to be shuffled coming in so that the 3-byte long samples were placed into 4-byte long storage locations (since no computer can deal with 3-byte long data types, the samples would be placed into a 32 bit integer type with the least significant byte set to 0). So “less in out work” in the sense of fewer bytes read from disk, but more work to get the data into a usable internal alignment.
the data would have to be shuffled coming in so that the 3-byte long samples were placed into 4-byte long storage locationsPossibly, but at the lowest level it will be a block read of hundreds of bytes at a time directly into memory. Loading each of those 24 bit values into a 32 bit register for processing will entail a little more work as you say, because 32 bits will be loaded, including 8 spurious bits which then have to be zeroed in the register.
Also loading 24 bit values will involve reads from odd numbered memory addresses, which means that sometimes a single read will have to load two consecutive memory words instead of one. In practice with modern machines the memory is 64 bits wide (DDR2 and DDR3) and there’s a lot of caching, so that won’t actually make much difference to the speed. At least the x86 and ARM architectures allow odd-addressed memory accesses for 16 and 32 bit values; it’s an illegal operation on some CPUs…