It's in the 'sigdelread_float' function (in d_delay.c) belonging to [delread~].
Miller changed
else if (x->x_delsamps > delwriter->x_cspace.c_n - DEFDELVS)
x->x_delsamps = delwriter->x_cspace.c_n - DEFDELVS;
to
else if (x->x_delsamps > delwriter->x_cspace.c_n)
x->x_delsamps = delwriter->x_cspace.c_n;
Because of subtracting DEFDELVS, the delay time for [delread~] would clip 64
samples too early.
Gesendet: Dienstag, 10. Mai 2016 um 01:47 Uhr
Von: "Alexandre Torres Porres" <[email protected]>
An: "Christof Ressi" <[email protected]>
Cc: "Miller Puckette" <[email protected]>, "pd-lista puredata"
<[email protected]>
Betreff: Re: Re: [PD] Delay Bug still buggy in 0.47-0
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 <[email protected]>:> 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][[email protected]]>
An: "Christof Ressi" <[email protected][[email protected]]>, "Miller
Puckette" <[email protected][[email protected]]>
Cc: "pd-lista puredata" <[email protected][[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][[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
