Ardour support

[agfline]

Continuation of thread https://github.com/agfline/LibAAF/issues/28

@x42, @johne53,

Hope you guys are doing well ! I thought it might be time to make a review of Ardour / AAF support ;)

First, there is still a major change pending, regarding how libaaf reads audio data from embedded audio files. As a reminder, libaaf currently loads each audio file into RAM, then writes audio file to disk before ardour imports it, which is pretty inefficient and might cause issues when little disk space or RAM is available (https://github.com/agfline/LibAAF/issues/28#issuecomment-2002139804, https://github.com/agfline/LibAAF/issues/28#issuecomment-2056648657).

The proposal (https://github.com/agfline/LibAAF/issues/28#issuecomment-2002142539) was to use a seek/read callback solution which was implemented a year ago (https://github.com/agfline/LibAAF/tree/cfb_stream_reader) and is still waiting to be merged (https://github.com/agfline/LibAAF/issues/28#issuecomment-2028959661) . John preferred that we wait for more testing before upgrading. We haven't had many testers on AAF since then, but should we move forward with it ?

Also, AAF import in Ardour remains tricky sometimes, because of the inability for the user to specify any parameter. IMO, the most important one would be to set the path to external audio files. Currently, one can work around this by moving all audio files next to the AAF file, which is tricky, undocumented and might not always be possible. Is the idea to make a GUI window for the AAF import still on the table ?

[johne53]

Hi Adrien and good to hear from you again.

I never managed to figure out why exactly, but Ben at Mixbus was never happy for me to publicise the fact that AAF was now available in Mixbus. It's been a massive drawback because Mixbus was always the best audience for AAF. For whatever reason, Ardour users rarely showed much of an interest in it. Maybe Ben didn't want it publicised until we gave AAF an improved UI? And I guess he wanted to see the error handling stuff reinstated?

The big problem now is that, code wise, Ardour and Mixbus have drifted a long way apart - and Robin is having to spend a lot of his time bringing everything back into sync. So I doubt he'll be able to do any AAF improvements just at the moment.

But having said that, I still think we got the order correct... our first AAF priorities should be to give it a better UI and error handling. Then once it's all a bit more useable we could re-investigate the cfb_stream_reader code?

[agfline]

Good to hear from you as well John !

I didn't know all that... Thanks for the clarification.

our first AAF priorities should be to give it a better UI and error handling. Then once it's all a bit more useable we could re-investigate the cfb_stream_reader code?

I agree that the UI is essential to promote the use of the AAF feature. Whether or not it should be prioritized over performance is up to you to decide. I guess it also depends on how much work it involves on the Ardour side.

I'll keep standing by then, let me know when you're ready ;)

[EDIT] In the meantime, I'm going to start a new branch to update the cfb_stream_reader branch with master. It’s quite late, and the process might take some time.

[x42]

Maybe Ben didn't want it publicised until we gave AAF an improved UI?

That, but also because not all sessions were imported correctly and parts are missing. Like pro-tools import this feature should mature at Ardour before Mixbus exposes it.

[johne53]

One more thing... I remember noticing various naming/styling differences between LibAAF and Ardour. For example, Ardour usually splits source files and header files into similarly named folders. For example 'AAFFileKinds.h' is here:-

aaf/aaf/AAFDefs

whereas in AAF itself, it's here:-

include/libaaf/AAFDefs

There are also naming and styling differences - such as this in Ardour:-

if (whatever) {
    ...
} else {
    ...
}

compared to this in libaaf:-

if (whatever)
{
    ...
}
else
{
    ...
}

Would it be worth trying to harmonize this stuff to make life easier for future merges?

[x42]

We just call clang-format for Ardour.

I tend to do that for all new source-files in Ardour's source-tree and when making significant changes to existing files (since some parts benefit from strategic clang-format on/off exceptions.