[PD] help making sense of [readsf~]

[Christof Ressi]

On 07.03.2024 04:43, Alexandre Torres Porres wrote:
>
>
> Em qui., 7 de mar. de 2024 às 00:27, Christof Ressi 
> <info at christofressi.com> escreveu:
>
>     (BTW, the equivalent SuperCollider object would be DiskIn UGen +
>     Buffer.cueSoundFile; there you don't even have the chance to skip
>     the buffering step.)
>
>
> This is a much better design. I don't mind the latency, but I'd really 
> like to tell the object to just play and it can then work out when it 
> is ready and start doing it :)
Keep in mind that this is not deterministic, i.e. playback will just 
start whenever the data is ready. This is probably fine for many uses 
cases, but if you want sample accurate playback, you'd need to wait 
until Buffer.cueSoundFile has completed before creating the DiskIn, 
similar to [readsf~].
>
> In fact, I would like to suggest a new "play" message, that would do 
> exactly this: "open" + "start', making sure there are no dropouts...

Actually, I had already thought about that! There could be an option 
that makes [readsf~] non-blocking, i.e. the perform routine does not 
wait on a condition variable if the buffer is empty, instead it would 
just output silence. This would be essentially the same behavior as 
DiskIn. I thought of doing this with a flag to the "open" message: [open 
-n <foo>, start(

But I agree that [play <foo>( looks much nicer and less obscure.

I just opened a feature request: 
https://github.com/pure-data/pure-data/issues/2205 :)

>
> Seems like a job to you by the way ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20240307/32fcb09c/attachment.htm>