filewatch question ?
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
thx.
f./
hi,
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?
thanks,
peter
just two words: halleluya - amen :-D
thx a lot, it's working now.