this is from the new 0.47 version, right?
Yes, hasn't changed.
No, whenever you change the overlap, [delwrite~] will change its size in samples. The patch I sent shows this - so it just adds or removes samples
Good to know!
yep. By thinking about it, I guess the sensible thing to do is only care about the block size of where the [delwrite~] is in.
That could be a compromise. And it's probably what Miller had in mind when he wrote:
#define DEFDELVS 64 /* LATER get this from canvas at DSP time */
Either way, extensive documentation is important.
Christof
Gesendet: Dienstag, 10. Mai 2016 um 01:16 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at, "Miller Puckette" mpuckett@imusic1.ucsd.edu Cc: "pd-lista puredata" pd-list@iem.at Betreff: Re: [PD] Delay Bug still buggy in 0.47-0
2016-05-09 18:56 GMT-03:00 Christof Ressi christof.ressi@gmx.at:Pd internally adds 64 samples to the delay time you specify for [delwrite~], so the user will think that buffer size = max. delay time. Here's the relevant part of the code: static void sigdelwrite_updatesr (t_sigdelwrite *x, t_float sr) /* added by Mathieu Bouchard */ { int nsamps = x->x_deltime * sr * (t_float)(0.001f); if (nsamps < 1) nsamps = 1; nsamps += ((- nsamps) & (SAMPBLK - 1)); nsamps += DEFDELVS; ... }
where DEFDELVS is defined as 64.
Of course this only works for block sizes of 64 samples. this is from the new 0.47 version, right? For me, the only sensible solution is that it knows about the block size and works it out for the user. Having the user to deal with this is just a bad design choice.
Not so easy I guess
But definitely better once worked out.
the block size of any reading object can change dynamically - should that always trigger a reallocation of the delay line? Probably not...
You're basically looking at a buffer resize, which I don't think is hard, just add or remove samples... by the way, resseting the delay length as a message would be another feature request I'd be intersted in, besides the clear method.
[delwrite~] already somehow cares for overlap and oversampling (...). But I don't know if it's only when DSP is turned on.
No, whenever you change the overlap, [delwrite~] will change its size in samples. The patch I sent shows this - so it just adds or removes samples
it's basically a design question
yep. By thinking about it, I guess the sensible thing to do is only care about the block size of where the [delwrite~] is in. Just make it clear in the documentation that a [delread~]/[delread4~] object won't work well if it has a bigger block size.
I personally like it when everything is as transparent as possible.
me too :) cheers