[WIP] soundfile meta data read/write

[danomatika]

This PR is a piggyback to #894 which adds basic meta data read and write via:

• read: [soundfiler] "-meta" read flag which outputs meta data as lists from the 2nd "info" outlet
• write: [writesf~] "meta" message which takes meta type name and a list and adds to the opened file's header, ie. send this after opening but before starting the write stream

So far, this is partially a proof-of-concept for the soundfile backend API, but can be expanded to cover much requested data access, ie. instrument & sampler meta data.

What's been implemented so far:

• aiff: text chunks (name, author, copyright, annotation)

[danomatika]

Things to figure out:

• Sending in meta messages along with open doesn't work, I'm not sure why. Ex:

    [open foo.aiff, meta name bar<

• Am I constructing the list output correctly? I would think the symbols wouldn't need to be send through a [symbol] to be detected as such.

• EDIT: Should the [soundfiler] list output should be prepended with a "meta" symbol?

[danomatika]

Arggg. Apple's Logic X saves loop information via proprietary chunks instead of the documented instrument or smaller chunks. :P

UPDATE: It seems Logic just uses Markers for this instead of the INST chunk and this is consistent between AIFF, WAVE, and CAF. At least this isn't completely hidden in a non-standard way, so dumping marker info should make it possible to edit loop positions in Logic and reading them in Pd; vice-versa when writing marker positions as long as the name matches what Logic expects. I'd say that can be an exercise left to the user.

Older devices like hardware samples probably use the INSTRUMENT chunk, I just can't find any example files with this info yet.

[danomatika]

As for the post/error on the background thread, this can probably be solved by adding an optional geterrstr() backend implementation function pointer. The background threads already save the errno and pass it back to the main thread for printing, so we can hook into that. I think it's very useful to provide feedback as to why the soundfile couldn't be opened/saved, ie. supported file type but unsupported format (32 bit int, etc).

I can also change the verbose soundfile header posts to fprintf(stderr, ...) and/or a compile time define. I don't want to remove this entirely as it has been extremely helpful for testing and iteration.

[danomatika]

Older devices like hardware samples probably use the INSTRUMENT chunk, I just can't find any example files with this info yet.

I was wrong about this. I now have AIFF loop point reading via the INST and MARK chunks. This seems to be consistent between the files I created and test files I have been sent. I also added COMT chunk extended comment text reading.

Another reason to avoid adding meta write support in the end: [soundfiler] write. When writing to a table, the file is opened, samples written, and the file is then closed. There isn't the extra explicit step between opening and starting to write as there is with [writesf~], so it would require changing the [soundfiler] write behavior based on some sort of message or flag.

[danomatika]

Latest commits add WAVE instrument, sampler (loop points), and info string meta data reading.

[danomatika]

Grrrr. CAF encodes loop points within regions within markers. You have to look through 2 sets of chunks to find sample positions.

[porres]

I was checking this now, and help file doesn't mention loop points yet, are they already implemented? would really like to test it!

[danomatika]

Honestly, this is a big mess I will not finish. There is nothing stable to test and I will be shelving this work for now as it quickly grew far too large.

[umlaeute]

Pd-0.52-0 is giving us [file] which is the first building block for reading/writing binary data.
afaict the [bytestruct] object (#1360, but this is not going to make it into Pd-0.52; i'll upload it as a deken library after Pd-0.52 is released) is the other missing piece to implement this entirely on the patch level ([bytestruct] comes with an example on how to read loop-data from a WAV file).

[umlaeute]

apart from that: should we delete this branch?

[danomatika]

Yes close delete this for now. I have a copy of the branch locally for possible later use.