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~].
Em qui., 7 de mar. de 2024 às 00:27, Christof Ressi <info@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 :)
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 ;)