[PD] Threading in Pd/libpd

[Giulio Moro]

>> 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?

Yes, that's the plan, by default I'd set it to the number of samples corresponding to the step determined by the specified overlap.

Giulio
>________________________________
> From: Jonathan Wilkes <jancsika at yahoo.com>
>To: Giulio Moro <giuliomoro at yahoo.it>; Pd-List <pd-list at lists.iem.at> 
>Sent: Thursday, 29 September 2016, 2:33
>Subject: Re: [PD] Threading in Pd/libpd
>
>> 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 at yahoo.com>
>>To: Giulio Moro <giuliomoro at yahoo.it>; Pd-List <pd-list at 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
>>
>>
>>
>>
>>
>>
>
>
>
>
>