saving audio to disk

jobro · 7 Feb 2012

I fully endorses this idea since it will make it easier to build tools like SFXR and the likes.

trogluddite · 17 Feb 2012

This is one of my biggest bugbears with producing SM .exe's - there is no live disk streaming. The best that SM can do is...

1) Set aside an area of memory (the 'mem' primitive). 2) Write data into the mem (using the 'R&D' mem write primitives). 3) Save the entire mem buffer to disk as one big chunk.

Besides this not allowing streaming, the other big limitations (IMHO) are...

Part (1), create a buffer - buffers cannot be dynamically resized, you have to fix the buffer at the largest size you are likely to use. Initialising a large buffer will make a large CPU spike (initialising every entry to zero).

Part (2), writing to the mem, happens at the full sample rate - however, the schematic must explicitly generate an index pointer so that samples are stored at sequential addresses within the buffer. It's also hard to selectively disable the write primitives - turning them off using selectors etc. results in a re-compile of the schematic, which is not always desirable. A 'dead zone' within the buffer for writing values you don't want is the easiest workaround - but that area will need trimming off before saving (see next paragraph...)

Part (3), saving to disk, will always save the complete mem buffer - there is no way to specify saving only the 'used' part of it. It is possible to work around this by converting the mem to a float array, truncating the array, then converting back to a (new) mem buffer - but as with initialising a buffer, this takes a lot of CPU resources (in my experience, it always interrupts any audio streams that are running - so saving while playing audio in the background does not work well).

I would love to be able to make .exe's that just stream their output to file - with huge HDD space available, you could just leave them in record, and never miss a moment of inspiration. At the moment, I resort to hanging a digital recorder off my soundcard outputs - it works, but it is a very clunky and expensive way to add what should be a simple function.

tester · 17 Feb 2012

I will be satisfied with following scenario: - setting the initial file (time) size to export - setting initial parameters of my sound to be exported - exporting it - to wav file (fixed sample rate - 44.1kHz, stereo, 16bit). but...

If the file size is 30-60 minutes (which can be done with using RAM - 300-600MB), then the export time matters.

Is the exporting time from exe app - is it real-time or max CPU speed?

trogluddite · 18 Feb 2012

tester wrote: Is the exporting time from exe app - is it real-time or max CPU speed?

I've not tried it with anything of the size you suggest, but AFAIK, all of those 'bulk data' operations (i.e. save, load, convert mem->array, etc.) work at max. speed. In fact, for my current project, that is part of the problem, as it causes those processes to hog the SM CPU thread until they are complete. I would prefer those operations to take place on a separate low-priority thread so that I can save recorded loops/samples without interrupting audio playback. Admittedly, wanting to truncate the buffer before saving is a big part of my problem - eliminating the need for float array conversion just to trim the audio would probably help a great deal. That could be solved by simply adding 'First sample' and 'Size' inputs to the Save Wave primitive - also cutting down the save time, and eliminating the need for off-line editing of the saved file.

tester · 19 Feb 2012

If it will perform well with large files/buffers, then I'm happy. Usually I shape my sounds and then export them as raw audio. And then tune it in DAW connecting with other stuff.