> 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" <[email protected]> An: "Christof Ressi" <[email protected]>, "Miller Puckette" <[email protected]> Cc: "pd-lista puredata" <[email protected]> Betreff: Re: [PD] Delay Bug still buggy in 0.47-0 2016-05-09 18:56 GMT-03:00 Christof Ressi <[email protected]>: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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
