Closed thp closed 3 years ago
Hmm, I am not so sure I want this... I mean, yeah, for sure, loading from memory can be useful, but I am also keen to keep the API surface for this pretty lean... it is the kind of thing that could quickly get bloated, and I am going for simplicity rather than power and flexibility.
That being said, I could see there being a need to load samples from memory, such as for generating sounds on the fly with code. But for that purpose, I think I would rather add a loadsamples
or something, which takes as parameters bits per sample (8/16), mono/stereo flag, number of samples, and a pointer to the samples, and returns a struct sound_t* from that. I think this would solve dynamic sample generation, and would also allow users to call drwav_open_file_and_read_pcm_frames_s16
themselves, and pass the result to loadsamples
, without needing a an engine function for loadwavbuf
.
Yeah, having loadsamples()
would do the trick.
I added the function now, but it is called createsound
instead of loadsamples
This is mostly a copy'n'paste of
loadwav()
, callingdrwav_open_memory_and_read_pcm_frames_s16()
instead ofdrwav_open_file_and_read_pcm_frames_s16()
. Might make sense to refactor and have only one internal implementation that just uses a buffer and read the file contents like is done ininstalluserfont()
(and that "load the complete file into memory" might make sense to be in a separate function), but I'll leave that up to you :)