Reading a sound from disk and writing it back immediately

Everything works so well.
But I have a problem when I read a sound from disk, do a quickie mod, and write it back.
The result is a zero-length sound.
If I write it to another filename it works great.
I assume that the file management overhead intrinsic to windows is busy and cannot comply…
So: Is there a way to tell if this has happened, maybe by the return value of the (s-save ~~~ ~~~) command?
And would it be better to just retry until success is seen in that return value,

Is there a way to busy that "windows file handling stuff" with something that requires an answer like (listdir ~~~ )?
Perhaps that will force the "windows stuff" to be ready for a new action, like saving to a file just opened for reading?
Thanks for your help!
~ Dalagar

The result is a zero-length sound.

So it destroys the original sound?

do a quickie mod

Is there a delay length that works? Is it the “quickie” part that Windows doesn’t like? I wonder if you’re overrunning one of Windows safety features.


or maybe there’s an error in your code.

Check the debug output.
Example, if I run this code in the Nyquist Prompt using the Debug button:

(setf filename "<fully-qualified-path-to-file>.wav")
(s-save *track* filename)

The debug output is:

Saving sound file to <fully-qualified-path-to-file>.wav
 44880  88740 
total samples: 117262 (2.659 seconds)

where “” is the actual file path.