Speed of multichannel audio file writing

[weefuzzy]

Work on #1 has revealed that, even for quite moderate cases, writing a multichannel audio file can take longer than processing, e.g.

./fluid-nmf -source ~/dev/flucoma-core/AudioFiles/Tremblay-ASWINE-ScratchySynth-M.wav -components 5 -resynth out.wav

At root, this is down to something that's already marked as a FIXME in the HISSTools audio file source: https://github.com/AlexHarker/HISSTools_Library/blob/5cf4a3ad60005cb8208f10be460607eb9b91248e/AudioFile/OAudioFile.cpp#L597

Basically, when writing channel-wise, the code spends a lot of time in seek() which is not a quick thing for a file.

For our part, the reading/storing/writing in the wrapper should change to be interleaved. This is not as huge a change as it seems:

1. Use readInterleaved from IAudioFile
2. In common with the BufferAdaptors for other hosts, rely on FluidTensorView to handle the layout logic (obtaining a channel -> reading a column when using interleaved layout)
3. Use writeInterleaved from OAudioFile
4. For CSV output we probably want to use the transpose of the interleaved data. I think.

[weefuzzy]

PR submitted, with hopefully much better performance for multichannel writes.

Still todo: at our end, keep the data in interleaved layout (this is faster still, according to my testing...)

[tremblap]

should we aspire for this in v1?

[weefuzzy]

It's not really in our hands. The PR code has been merged into an experimental branch on HISSTools, but I don't think that branch has yet made it to main

[AlexHarker]

I think this code is now merged, or on the way to being merged, so once we are header-only we should retest this.