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