Is fout supposed to work on Csound WASM? It seems to write a file that we can open, but the data in it does not seem to be correct
(just a buzz). Here’s some test code
0dbfs = 1
nchnls = 1
instr 2
ain inch 1
fout "./test.wav",-1,ain
out ain
endin
schedule(2,0,10)
instr 3
a1 diskin "./test.wav",1,0,1
out a1
endin
schedule(3,11,10)
Checking with filelen, the file is only 3 ms long
Here is an example which writes a file using fout and then presents a link for download. Thanks to Hlöðver for his help with this one.
here where?
Anyway, if that works, then I don’t know why my code doesn’t.
Sorry, here:
https://editor.p5js.org/rorywalsh/sketches/9VmTcOfPX
But in this example I don’t try to access the file I just wrote in Csound. I see no examples of doing this in the test files either, so I’m not sure it’s possible?
https://github.com/csound/csound/blob/master/wasm/browser/tests/tests.js
The file seems to be seen and opened, it just doesn’t seem to have much data in it.
The code I have works on the desktop so I would have expected to work on WASM if fout is able to write data.
In your example do you have to stop Csound before making the data available for download? Or can you record
and download while Csound continues to run?
I didn’t try that. I was specifically looking to save a performance. I’m using the “realtimePerformanceEnded” event, but I guess a button click would work too?
ah, that might the difference. It could be that the file is not properly closed before the performance is finished.
Yes that’s exactly what happens. The file buffers are collected, but the file headers are written to the open file handler at the end of the performance, maybe this could be improved such that the file headers are written first and the buffers are thereafter written contiguously, without a seek to position 0.
On the desktop, fout closes the file when the instrument is deinitialised (the instance stops running). Perhaps that’s the behaviour we should seek to emulate?
Prof. Victor Lazzarini
Maynooth University
Ireland
I didn’t do anything special, I just receive the filesystem callback as they are fired from the wasm runtime. But I will take a look at what’s happening, I need to anyway have a look at a filesystem issue that has been reported from one ftgen function. I’ll update after I’ve found time for this 
With wasm everything is using web client apis, so any calls from wasm
to the filesystem use this api
I did consider using the old html FileSystem api. But the problem is that you can’t access the FileSystem object across worker threads. File files are stored as Uint8Array buffers next to the wasm context, and are transferred to the main thread as Transferrable https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Transferable_objects and with the Uint8Array, the user can do anything with the data, including creating “new File()” or “new Blob()” or new MediaStream…