> So having a look at the source code I'd say what would happen is that

> the second block prints the samples of the sound file.

> I guess the point you are trying to make here is that a threaded version

> of [fft~], the perform routing should block if the samples are not ready in

> time. That sounds perfectly plausible (and doable) to me.

> Or am I missing your point?

That's right. But on the broader scale I'm pointing out how easy it is to

overlook determinism in these cases.

> I'd add that right now, if the system cannot compute an FFT on time and it

> causes dropouts, you have to solve that by increasing Pd's delay. With a

> threaded implementation, you could add a delay for that specific subpatch instead of the whole of Pd.

I'm having trouble seeing how that would work in practice. Would the

user specify the delay in ms/blocks as an argument?

> Giulio

From: Jonathan Wilkes <jancsika@yahoo.com>
To: Giulio Moro <giuliomoro@yahoo.it>; Pd-List <pd-list@lists.iem.at>
Sent: Wednesday, 28 September 2016, 23:00
Subject: Re: [PD] Threading in Pd/libpd

> Thanks Jonathan.

> Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for obvious reasons involving system calls.

>> Can you guarantee that the revisions you've implemented generate the same output as Pd Vanilla, for all cases?

> I'd rather say it does not, in all cases. At the very least there is going to be a delay involved. But, if this brings to a different behaviour, yet still deterministic, would that be bad? After all, the above mentioned objects are not deterministic themselves, yet they are widely used, with a very high success rate.

udpsend and udpreceive are special cases because the protocol itself rules out the kind of determinism we're discussing.

So let's focus on readsf~ instead.

Suppose readsf~ is reading a sound file and outputs 3 blocks-- block 1, block 2, and block 3. The patch is outputting the sound file to the sound card, so we are
listening to the sound file as Pd is running.

Now, imagine this happens:

1st block: readsf~ perform routine finishes in time to output a block to the soundcard on schedule.
2nd block: perform routine takes longer to compute, and it misses the deadline set for the next block to be delivered to the soundcard. So we hear a dropout.
3rd block: perform routine finishes in time to meet the deadline.

Now, suppose we were debugging our patch by outputting each block of samples
to the console. Here's the question, then: what gets printed for the 2nd block?
Does Pd print out the samples from the sound file that missed the deadline, or
does it print out 64 zeroes?

-Jonathan