On 07.03.2024 04:43, Alexandre Torres Porres wrote:
Em qui., 7 de mar. de 2024 às 00:27, Christof Ressi
<[email protected]> 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 ;)
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
