So to summarize, the possible approaches are:
1. Stealing from client-malloc; fluid will call free(). Won't work with
different allocators other than malloc.
2. Stealing from client-fluid_alloc; fluid will call fluid_free(). At
least it lets fluid control the allocator.
3. Borrowing; fluid will not free memory. Requires complicated memory
management in the client.
4. Borrowing, with a "destructor" callback. Lets the client control
allocation and freeing, and can easily simulate #1 or #2.
5. Copying. Client must free, but can do it right away. Easiest method,
but inefficient.
Good summary. I think the reason I thought of 5 as the most flexible one would be because if we ever changed it to do the parsing at add_mem time, we would just skip the copy, and no additional memory management would be necessary.
Oh I see. Well if we went with #2 it would still be easy to extend it to do parsing at "add time"; we would just make it free the memory immediately. The only problem is it would now be inefficient if a client *did* do a copy. Also the interface ("it reads from the buffer then frees the buffer for some reason") would no longer make much sense. But it wouldn't break clients, at least.
I suppose the question is then, is there a serious intent (not now, but in the future) to modify the behaviour so it parses the MIDI file at "add time"? If so, #5 makes the most sense. If not, I think #2 still makes the most sense.
Note that initially your concern was about having multiple MIDI files in memory at a time (which is why you suggested the compromise of still storing filenames at "add time" until "play time" when the full load-and-parse is done). It's probably not too big of a concern given that I've never seen a MIDI file above 1MB, but something to consider.
The decision won't really affect the implementation (we can easily change garbage collection strategies after this patch has been written), it's just something we need to decide on before committing to the trunk, as it will affect the clients.