Use mmap in file-backed Fragment objects

[gctucker]

Fragment objects can take a large amount of memory and are often saved as intermediate SAF (Splat Audio Format) files when generating complex compositions. It would be a lot more efficient to use mmap when operating on such Fragment objects. This should only be optional as it is not wanted for small temporary Fragment objects such as those generated by the ParticleGenerator, and a file system may not always be available to store temporary SAF files.

An optimal way to do this would be to change the SAF format to follow the data format of struct splat_fragment with a buffer per channel instead of interleaved samples as can be found in WAV of current SAF files. This would allow working directly on SAF files mapped into the channel buffers, with no extra reformatting and copy when saving the file. Otherwise, temporary files would need to be used especially to mmap the sound buffers; this may also be useful for large temporary buffers that are not explicitly saved into files but it is not the general use-case.

When creating Fragment objects by opening SAF files, mmap should be used by default. It may be used as well with temporary SAF files when opening large files of other formats such as WAV. It should be optional on newly created Fragment objects with a Fragment.mmap(path) method. It may also be useful to add a property to Fragment objects to know whether they are already mapped.

[gctucker]

See PR #22.