[PD] Delay Bug still buggy in 0.47-0

[Alexandre Torres Porres]

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.ressi at 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" <porres at gmail.com>
> An: "Christof Ressi" <christof.ressi at gmx.at>, "Miller Puckette" <
> mpuckett at imusic1.ucsd.edu>
> Cc: "pd-lista puredata" <pd-list at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160509/9e159e6e/attachment-0001.html>