Hi Oliver,
there have been some regressions in Pd 0.52 concerning [readsf~] and [writesf~] that should be fixed with https://github.com/pure-data/pure-data/pull/1672.
Can you try latest master and see if your problem persists?
Cheers,
Christof
On 05.10.2022 22:01, Dan Wilcox wrote:
Howdy Oliver,
I suggest opening an issue on Github. If this was working with 0.51, then my sound file overhaul did not change this but perhaps some additional regression fixes broke it in 0.52.
On Oct 5, 2022, at 9:45 PM, pd-list-request@lists.iem.at wrote:
Message: 2 Date: Wed, 5 Oct 2022 21:36:19 +0200 From: oliver oliver@klingt.org To: Pd-List pd-list@lists.iem.at Subject: Re: [PD] PD 0.52 bug ? ... [bang~ driven playback] Message-ID: b5ef9f3e-19eb-10ed-bc81-e10f7443aca9@klingt.org Content-Type: text/plain; charset=UTF-8; format=flowed
Peter P. wrote:
Oliver,
can't really comment on your error, but am wondering why you might want to trigger each dsp block separately, especially opening the file from hard disk for each dsp block over and over again?
i'm using this method quite often for sync purposes (video-synching mostly, but also sending synch messages with udp etc.), since readsf~ doesn't output it's playback position.
it's also nice, to scratch around in the the audio file without having to load it into RAM.
As i said before,this method (as strange as it may seem) used to work without any problem on basically any system i used (even on RPIs and old slow netbooks) up until PD 0.52.
best
Oliver
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list