Tough review / should it be deprecated?

[dy]

This package starts to be a blocker for reliable audio development, because of a set of doubtful solutions and unanswered questions.

Rationale to this package:

1. Avoid copying new data into some allocated buffer and instead just save reference to data chunks.
2. Quickly insert/remove data from any part of the buffer.

• 1 should imply that new data chunks can be of any audio format, not only AudioBuffer, to be able to mutually extract and process collected data of different types, eg. interleaved and planar together. If AudioBuffers are forced, that makes for opinionated data format and anyways requires converting data first. Therefore, the 1 is not met.
  • consequently, converting/copying data from any source type into allocated buffer could be done directly in audio via set method, avoiding audio-buffer-list.
    • 👎 that makes inserting new data w/o need for conversion slow.
• 2 is implemented in audio-buffer-list as split and join, which postpone copying new data from write to edit.

Not addressed cases here:

3. History of modifications.
4. Collaborative editing.
5. Branching.

Inspiration:

• xray RGAsplit
• storing a set of operations, like gain etc., rather than modifying content directly, which allows for faster updates and does not lose data precision.
  • We may not need to store peer id, but linked list of operation-nodes with id, content, tombstone flag and nextNodeId from RGA may make sense.