[PD] PD 0.52 bug ? ... [bang~ driven playback]
danomatika at gmail.com
Wed Oct 5 22:01:18 CEST 2022
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 at lists.iem.at wrote:
> Message: 2
> Date: Wed, 5 Oct 2022 21:36:19 +0200
> From: oliver <oliver at klingt.org <mailto:oliver at klingt.org>>
> To: Pd-List <pd-list at lists.iem.at <mailto:pd-list at lists.iem.at>>
> Subject: Re: [PD] PD 0.52 bug ? ... [bang~ driven playback]
> Message-ID: <b5ef9f3e-19eb-10ed-bc81-e10f7443aca9 at klingt.org <mailto:b5ef9f3e-19eb-10ed-bc81-e10f7443aca9 at klingt.org>>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Peter P. wrote:
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list