hello.
i just want to report a few bugs that i can spot with
the [readsf~]/[writesf~] couple ..
a)
i have already wrote about this, and i'll write again, cause i'm
very sure on this one.
when i write a file with this command:
[open -byte 4 -nextstep -little -rate 96000 /tmp/recording-ex01(
it produces a file which is recognised by unix command file(1)
as just a 'data' file, and then opening it in Snd editor it come
up as a raw pcm and i set the header values and write the header
to it, ..then file actualy gives this output:
'/home/110101/mtk/rec/recording-ex01.snd: Sun/NeXT audio data: stereo, 96000 Hz'
instead of '/tmp/recording-ex01.snd: data'
so trying to load the modified header file into [readsf~]
doesn't parse the header, but trying to load the unmodified one
is okay.
probably it's about endianes of the magic byte ..
well.. it could be actually not a pd bug but Snd and file(1) bug
.. but they are two, i'll try to check with other programms but
it's a majority to me already.
b)
[readsf~] heppends to segfault Pd when i load my 4channel 10min
lond file which was recorded with [writesf~] with above [open( command.
i run Pd (version 0.41-4) on amd64 linux machine which has 1g of
ram ..
it segfaults in a big patch, which i'll hopefully manage to
package soon ..it has really a lot of abstraction that i made
and quite many subpatches.
i did manage to get it working with some subpatches [switched~]
off. so i think it's definetly some memory allocation problem in
there, could be in soundfiler code, or may be in some other
objects that i have there ..(there are many VUs which are now in
[switch~]ed subpatches and when i'm kindda carefull it doesn't
crash ;)
well, anyhow i reckon that readsf~ needs some replacment for my purpose ..
cause the file is that big .. (du -hs reports 1022M)
perhaps, i could experiment on system with ONLY puredata running,
but there a lot of important processes which i cannot kill at the moment..
cheers,
--
ilya .d