<div dir="ltr">something changed in 0.47, as your patch now works... I wonder what...<div><br></div><div>it was maxing out to the given delay line, but 64 samples less than that.</div><div><br></div><div>cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-09 20:34 GMT-03:00 Christof Ressi <span dir="ltr"><<a href="mailto:christof.ressi@gmx.at" target="_blank">christof.ressi@gmx.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> this is from the new 0.47 version, right?<br>
<br>
</span>Yes, hasn't changed.<br>
<span class=""><br>
<br>
> 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<br>
<br>
</span>Good to know!<br>
<span class=""><br>
<br>
> 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.<br>
<br>
</span>That could be a compromise. And it's probably what Miller had in mind when he wrote:<br>
<br>
#define DEFDELVS 64             /* LATER get this from canvas at DSP time */<br>
<br>
<br>
Either way, extensive documentation is important.<br>
<br>
Christof<br>
<br>
<br>
 <br>
<br>
Gesendet: Dienstag, 10. Mai 2016 um 01:16 Uhr<br>
<span class="">Von: "Alexandre Torres Porres" <<a href="mailto:porres@gmail.com">porres@gmail.com</a>><br>
</span>An: "Christof Ressi" <<a href="mailto:christof.ressi@gmx.at">christof.ressi@gmx.at</a>>, "Miller Puckette" <<a href="mailto:mpuckett@imusic1.ucsd.edu">mpuckett@imusic1.ucsd.edu</a>><br>
Cc: "pd-lista puredata" <<a href="mailto:pd-list@iem.at">pd-list@iem.at</a>><br>
Betreff: Re: [PD] Delay Bug still buggy in 0.47-0<br>
<div class="HOEnZb"><div class="h5"><br>
 <br>
 <br>
2016-05-09 18:56 GMT-03:00 Christof Ressi <<a href="mailto:christof.ressi@gmx.at">christof.ressi@gmx.at</a>>: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:<br>
static void sigdelwrite_updatesr (t_sigdelwrite *x, t_float sr) /* added by Mathieu Bouchard */<br>
{<br>
    int nsamps = x->x_deltime * sr * (t_float)(0.001f);<br>
    if (nsamps < 1) nsamps = 1;<br>
    nsamps += ((- nsamps) & (SAMPBLK - 1));<br>
    nsamps += DEFDELVS;<br>
    ...<br>
}<br>
<br>
where DEFDELVS is defined as 64.<br>
<br>
Of course this only works for block sizes of 64 samples.<br>
 <br>
this is from the new 0.47 version, right? <br>
 <br>
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.<br>
 <br>
> Not so easy I guess<br>
 <br>
But definitely better once worked out.<br>
 <br>
> the block size of any reading object can change dynamically - should<br>
>  that always trigger a reallocation of the delay line? Probably not...<br>
<br>
You're basically looking at a buffer resize, which I don't think is hard, just add or remove samples...<br>
 <br>
by the way, resseting the delay length as a message would be another feature request I'd be intersted in, besides the clear method.<br>
<br>
> [delwrite~] already somehow cares for overlap and oversampling (...).<br>
> But I don't know if it's only when DSP is turned on. <br>
 <br>
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<br>
 <br>
> it's basically a design question<br>
 <br>
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.<br>
 <br>
> I personally like it when everything is as transparent as possible.<br>
 <br>
me too :)<br>
 <br>
cheers<br>
</div></div></blockquote></div><br></div>