Hans Roels wrote:
Hello,
hi.
how does this relate to "Arduino/SRF05" to which thread it references?
Sometimes when I record audio in Pd, a wave file is created that Pd
[...]
problem yet but I'm trying... (I think it has something to do with using 'writesf' in an abstraction).
I 'm working on Windows XP and this problem occured in Pd 0.40.3 and in 0.42-4.
your problem is most likely related to not properly closing the soundfile. you MUST send a [stop( message to [writesf~] in order to "finalize" the wav (that is: replace the dummy length in the header with the proper one, which is only known at closing time)
fgmasdr IOhannes
At 19:32 2/03/2009, you wrote:
Hans Roels wrote:
Hello,
hi.
how does this relate to "Arduino/SRF05" to which thread it references?
Sometimes when I record audio in Pd, a wave file is created that Pd
[...]
problem yet but I'm trying... (I think it has something to do with using 'writesf' in an abstraction). I 'm working on Windows XP and this problem occured in Pd 0.40.3 and in 0.42-4.
your problem is most likely related to not properly closing the soundfile. you MUST send a [stop( message to [writesf~] in order to "finalize" the wav (that is: replace the dummy length in the header with the proper one, which is only known at closing time)
I did send a stop message to writesf~, I recorded a sound 10 times with exactly the same abstraction and 4 files had this problem... (the other 6 files were OK).
fgmasdr IOhannes
I think/hope that I managed to isolate the problem with writesf~ and readsf~. There are two patches in attach that print out every step that you take so one can't forget to click 'open' for example, it also measures the time between the 'open' and 'start' command. Copy these 2 patches in the same folder.
Try this test a few times:
(test writesf~) 4. open a file (comment 1 in 'rec') 5. start recording (comment 2 in 'rec') 6. stop the recording (comment 3 in 'rec') 7. send 'print' to writesf~ (comment 4 in 'rec') (test readsf~) 8. open a file (comment 5 in 'rec') 9. play a file (comment 6 in 'rec') 10. answer question (comment 7 in 'rec') 11. send 'print' to readsf~ (comment 8 in 'rec') 12.close Pd & don't save any changes
I tried this 10 times on Windows XP (Pd 0-42-4) and 10 times in Mac Os X 10.3.9 (Pd 0-40-2) and readsf~ and writesf~ never worked and Pd only created a wav file with the right name but without sample data. Be sure to do exactly the required steps and nothing more. If for example you open 'test audio and midi' in de Media menu (or you delete and restore an audio cable within the abstraction 'rec') before step 12, the opened file will start playing, even if it was 30 seconds ago that you opened and tried to play the sound file. If you try recording (step 4 - 7) everything will work now n this case.
This is what Pd prints (print commands in abstraction 'rec') when readsf and writesf don't work:
print: open C:/Program Files/pd042-4/bin/aa.wav print: start time_beween_open_and_start: 2774.78 print: stop time_beween_start_and_stop: 3297.23 state 0 fifo head 0 fifo tail 0 fifo size 262144 fd -1 eof 0 print: open C:/Documents and Settings/Bureaublad/pianob7.wav print: 1 time_beween_open_and_start: 3668.75 readsf_sound?: no state 2 fifo head 70496 fifo tail 0 fifo size 262144 fd -1 eof 1
This what Pd prints when writesf and readsf do work after 'test audio and midi' was opened after step 11 print: open /elektromuziek/extra.wav print: start time_beween_open_and_start: 1364.17 print: stop time_beween_start_and_stop: 1834.38 state 0 fifo head 161792 fifo tail 161792 fifo size 262144 fd -1 eof 0 print: open /elektromuziek/PIANOB7.WAV print: 1 time_beween_open_and_start: 1428.03 readsf_sound?: yes state 0 fifo head 70496 fifo tail 70400 fifo size 262144 fd -1 eof 1
I hope someone can solve this problem...
Hans r
At 19:32 2/03/2009, IOhannes m zmoelnig wrote:
Hans Roels wrote:
Hello,
hi.
how does this relate to "Arduino/SRF05" to which thread it references?
Sometimes when I record audio in Pd, a wave file is created that Pd
[...]
problem yet but I'm trying... (I think it has something to do with using 'writesf' in an abstraction). I 'm working on Windows XP and this problem occured in Pd 0.40.3 and in 0.42-4.
your problem is most likely related to not properly closing the soundfile. you MUST send a [stop( message to [writesf~] in order to "finalize" the wav (that is: replace the dummy length in the header with the proper one, which is only known at closing time)
fgmasdr IOhannes
Hans Roels wrote:
I think/hope that I managed to isolate the problem with writesf~ and readsf~. There are two patches in attach that print out every step that you take so one can't forget to click 'open' for example, it also measures the time between the 'open' and 'start' command. Copy these 2 patches in the same folder.
the answer is simple: there is a (known) bug in Pd that does not re-start the dsp-graph in some situations when live-patching. i think there is at least 1 bug-report in the sf bug-tracker.
so what happens here is: after you have started the dsp you create [rec] but for whatever reasons, the dsp-graph is not updated and thus your [writesf~] is not working at all.
you can test this by: adding [env~] plust floatatom to [osc~] in your [rec] patch. save it. then re-start Pd, open main.pd, create [rec], open it up and lo-and-behold, the numberbox might still show 0 (and is not updated by [env~])
workaround: manually restart the dsp after you have dynamically created an object: [loadbang]->[; pd dsp 0; pd dsp 1(
fgnmasdr IOhannes
thanks a lot for this information, I added the [loadbang]->[; pd dsp 0; pd dsp 1( to my recording abstraction and after testing it a few times, this seems more reliable. Hans r
At 12:40 3/03/2009, IOhannes m zmoelnig wrote:
Hans Roels wrote:
I think/hope that I managed to isolate the problem with writesf~ and readsf~. There are two patches in attach that print out every step that you take so one can't forget to click 'open' for example, it also measures the time between the 'open' and 'start' command. Copy these 2 patches in the same folder.
the answer is simple: there is a (known) bug in Pd that does not re-start the dsp-graph in some situations when live-patching. i think there is at least 1 bug-report in the sf bug-tracker.
so what happens here is: after you have started the dsp you create [rec] but for whatever reasons, the dsp-graph is not updated and thus your [writesf~] is not working at all.
you can test this by: adding [env~] plust floatatom to [osc~] in your [rec] patch. save it. then re-start Pd, open main.pd, create [rec], open it up and lo-and-behold, the numberbox might still show 0 (and is not updated by [env~])
workaround: manually restart the dsp after you have dynamically created an object: [loadbang]->[; pd dsp 0; pd dsp 1(
fgnmasdr IOhannes