the process in this patch is to watch when the file is written on the disk then play it.

following the advices of ej i used filewatch.

the process works fine but only for recording less than 8 seconds.

and this recording machine is mainly for automatic recording more than 30 sec.

- could somebody can test if the problem happens on another computers ?

it does on mine (titanium, alu, macbook).

i don't understand the logic of that...
the process in this patch is to watch when the file is written on the disk then play it.

following the advices of ej i used filewatch.
the process works fine but only for recording less than 8 seconds.
and this recording machine is mainly for automatic recording more than 30 sec.

- could somebody can test if the problem happens on another computers ?
it does on mine (titanium, alu, macbook).
- and so explain to me what's happen ?
- what could be the solution ?

here's the patch: http://www.pan-etc.net/fp/rec-test.zip

filewatch-question

my max window is giving me the message "freeing zero signal?". could 

anyone please tell me where it is coming from? i'm not sure if it is 

causing me problems, but it has me baffled.

the patch as it is is way too complicated and messy to post here, but, of 

note, it involves a [poly~] (10 instances) of [reson~]s, and outside of 

the poly, several [tap.adapts~]s, [tap.anticlicks~], [yafr2]s, and 

[bonks~]. there is also minimal [thispatcher] scripting in my version of 

[yafr2]. four [sfplay~]s run simultaneously, and there are no buffers. the 

patch blows up quite often, i'm not sure where or why, though i suspect in 

[yafr2]. that fact doesn't bother me too much, at least for now.

i will reduce the patch if that help someone solve my little problem, but 

if someone recognizes "freeing zero signal?" and could tell me about it, 

and, as a side issue, my scripting is simply the creation then removal of 

[*~] every 5 seconds, intentionally to disrupt the audio chain. when max 

is the application in front, it runs smoothly, with a nice little hiccup 

every 5 seconds, but if i bring, say, terminal or even finder, to the 

front, the next bang of the script turns off audio altogether and requires 

my max window is giving me the message "freeing zero signal?". could 
anyone please tell me where it is coming from? i'm not sure if it is 
causing me problems, but it has me baffled.

the patch as it is is way too complicated and messy to post here, but, of 
note, it involves a [poly~] (10 instances) of [reson~]s, and outside of 
the poly, several [tap.adapts~]s, [tap.anticlicks~], [yafr2]s, and 
[bonks~]. there is also minimal [thispatcher] scripting in my version of 
[yafr2]. four [sfplay~]s run simultaneously, and there are no buffers. the 
patch blows up quite often, i'm not sure where or why, though i suspect in 
[yafr2]. that fact doesn't bother me too much, at least for now.

i will reduce the patch if that help someone solve my little problem, but 
if someone recognizes "freeing zero signal?" and could tell me about it, 
then i'd appreciate it a lot!

and, as a side issue, my scripting is simply the creation then removal of 
[*~] every 5 seconds, intentionally to disrupt the audio chain. when max 
is the application in front, it runs smoothly, with a nice little hiccup 
every 5 seconds, but if i bring, say, terminal or even finder, to the 
front, the next bang of the script turns off audio altogether and requires 
startwindow to be banged. any thoughts?

filewatch question ?