>> 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 <[email protected]> >To: Giulio Moro <[email protected]>; Pd-List <[email protected]> >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 <[email protected]> >>To: Giulio Moro <[email protected]>; Pd-List <[email protected]> >>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 >> >> >> >> >> >> > > > > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
