[PD] issues with [readsf~]/[writesf~]

[Hans-Christoph Steiner]

Please add these to the bug tracker.

.hc

On Jun 20, 2008, at 5:26 AM, errordeveloper at gmail.com wrote:

>
> 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
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



------------------------------------------------------------------------ 
----

If you are not part of the solution, you are part of the problem.