something changed in 0.47, as your patch now works... I wonder what... it was maxing out to the given delay line, but 64 samples less than that.
cheers 2016-05-09 20:34 GMT-03:00 Christof Ressi <christof.re...@gmx.at>: > > 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" <por...@gmail.com> > An: "Christof Ressi" <christof.re...@gmx.at>, "Miller Puckette" < > mpuck...@imusic1.ucsd.edu> > Cc: "pd-lista puredata" <pd-l...@iem.at> > Betreff: Re: [PD] Delay Bug still buggy in 0.47-0 > > > > 2016-05-09 18:56 GMT-03:00 Christof Ressi <christof.re...@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 >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list