[PD] 0 length delay in delwrite~

Sat Dec 12 23:14:10 CET 2015

And I think the same logic will apply to any [delread~] buffer explicitly
set to <= 60 samples ([delread~] rounds up from the input to the nearest
multiple of 4).

On Sat, Dec 12, 2015 at 4:49 PM, Matt Barber <brbrofsvl at gmail.com> wrote:

> There's one trick that works for zero delay and [delwrite~ 0], based on
> the code of [delread~]: provide a negative delay time (with abs(delay time)
> > 1 sample).
>
> Here's what's going on in Alexandre's patch.
>
> [delwrite~ 0] sets up a buffer that is 68 samples long, plus four extra
> for interpolation in [vd~], which we needn't worry about here.
>
> delwrite's float method is this:
>
>
> /*---------------------------------------------------------------------------*/
> static void sigdelread_float(t_sigdelread *x, t_float f)
> {
>     int samps;
>     t_sigdelwrite *delwriter =
>         (t_sigdelwrite *)pd_findbyclass(x->x_sym, sigdelwrite_class);
>     x->x_deltime = f;
>     if (delwriter)
>     {
>         int delsize = delwriter->x_cspace.c_n;
>         x->x_delsamps = (int)(0.5 + x->x_sr * x->x_deltime)
>             + x->x_n - x->x_zerodel;
>         if (x->x_delsamps < x->x_n) x->x_delsamps = x->x_n;
>         else if (x->x_delsamps > delwriter->x_cspace.c_n - DEFDELVS)
>             x->x_delsamps = delwriter->x_cspace.c_n - DEFDELVS;
>     }
> }
>
> /*---------------------------------------------------------------------------*/
>
> Here, I believe that because the write and read are sorted, x->x_zerodel
> == 0. Also DEFDELVS == 64, and delwriter->x_cspace.c_n == 68;
> So with [delread~ 0], x->x_delsamps is initialized to 0 + 64 - 0. The
> first if statement fails, but the second one passes, and x_delsamps is set
> to c_n - DEFDELVS = 4.
>
> Let's pick it up after [delwrite~]'s second block calculation. It's just
> gotten the range 64:127 in its input vector, and written indices 64:67 with
> 64:67, and indices 0:59 with 68:127. Its phase is now at index 60. With
> x_delsamps set to 4, [delread~ 0] begins reading at index 60-4 = 56, which
> contains the value 124. For four samples, the difference between input and
> output (the [-~] in the patch) is -60. Indices 60:67 contain values 60:67,
> and 0:59 contain 68:127; the difference between input and output is
> therefore 8 for the 60 remaining samples of the block. Hence the
> oscillation between 8 and 60 in the number box, with 8 appearing most of
> the time.
>
> If you set a negative delay, the first if statement passes, and x_delsamps
> is set to 64, as it should be to get zero delay (that is, it's reading the
> last 64 samples written to the delay buffer, so there's zero difference
> between input and output).
>
> Matt
>
>
>
>
> On Sat, Dec 12, 2015 at 12:00 PM, Alexandre Torres Porres <
> porres at gmail.com> wrote:
>
>> > Order forcing works well for me. Just set the [delwrite~] to 10 (
>>
>> but weirdness arises from 0 length delay.
>>
>> > If a delay of zero WAS actually permitted, these would form infinite
>> loops.
>>
>> Don't think so, depends on what a 0 delay is. If it is "no delay", and by
>> that I mean "No Buffer", then it only outputs 0 values, right?. In other
>> words, nothing happens, no infinite loop, nothing, just zeros...
>>
>> but if instead of zeros it does have some buffer length in it, then a
>> feedback delay will always de delayed at least one block size, so no
>> worries about feedback loop.
>>
>> Actually, you need to set delread to "0" for a minimum block size delay.
>> Perhaps you meant you couldn't or shouldn't put a "0" delay time in the
>> delread~ object for feedback, but actually you NEED to do that.
>>
>> Thing is that I just use delwrite~ and delread~ with 0 length arguments
>> for both and a block size of 1 to allow single sample feedback. I do it
>> cause I wanted the minimum delay buffer size as possible and I didn't want
>> to write in tiny and long and boring numbers according to one sample size
>> depending on sample rate.
>>
>> Since it was working, I had just always assumed it would create a buffer
>> of one block.
>>
>> This is not what's really happening as I see it.
>>
>> I don't really care that much on what happens, doesn't seem like a big
>> deal, but it was nice to understand this behaviour. It doesn't seem very
>> consistent, that's all I can say...
>>
>> Now, what it actually does is really just a matter of design choices. It
>> could very much just create no delay buffer at all, where you'd get 0
>> values perhaps, like I imagined. That's silly anyway...
>>
>> Or... it could be only one sample... or one block... I had assumed out of
>> nowhere that it could be a block size, but it could much be just a single
>> sample, which seems to make sense and it'd be cool I guess.
>>
>> What's really bad is that you need to always put a value that is at least
>> one block size. It's a bug considering the documentation clearly stated
>> that the design was really supposed to be a delay between 0 and max delay
>> size, but one way or another, it's really annoying doing all this math
>> as a workaround, when it's just a matter of coding it properly to allow any
>> size greater than 0 and smaller than a block size (in orther words, to fix
>> it).
>>
>> > If you, however, want a simple block delay in a feedback loop,
>> > just use a pair of [send~] and [receive~].
>>
>> don't work for block size < 64
>>
>> > specifying the buffer size makes much more
>> > sense then giving a maximum delay time
>>
>> Those two things means the same to me, where maximum delay time = buffer
>> size. I don't get this.
>>
>> > [delwrite~] object would need to keep track of this
>>
>> sure, whatever, why not?
>>
>> by the way, that's the one that defines the max delay length (or buffer
>> size), (and there can be only one, by the way) - so it only needs to keep
>> track of its block size to work out the proper buffer size.
>>
>> I might see an issue if delread~ is in a subpatch that has a longer block
>> size, but I don't wee why anyone would need that, and perhaps just say you
>> shouldn't do it.
>>
>> I think we've discussed this before, perhaps just make sure both are in
>> the same block size. I for one, never needed them to be in different block
>> sizes, makes no useful sense.
>>
>> But anyway, I guess Miller is the one that should hop in and share his
>> thoughts.
>>
>> and lets not forget the "clear" method, also important :)
>>
>> cheers
>>
>>
>> 2015-12-12 12:33 GMT-02:00 Roman Haefeli <reduzent at gmail.com>:
>>
>>>
>>> On Fri, 2015-12-11 at 14:26 -0200, Alexandre Torres Porres wrote:
>>> > hi, I'm checking that if you put a 0 length delay in delwrite~ you
>>> > still have some buffer
>>> >
>>> >
>>> > what's up with that? and how does it work? how big is it when you
>>> > don't define it?
>>>
>>> Don't know. I confirm that weirdness happens when setting [delwrite~] to
>>> 0. In other words: The only value that does not justify using a delay at
>>> all shows unexpected behavior. I can live with that.
>>>
>>> > I always get a minimum dealy even with order forcing (and different
>>> > values depending on extended orvanilla), it seems the delay needs to
>>> > be at least the block size to work properly
>>> >
>>> >
>>> > moreover, I can't have an order forcing
>>>
>>> Order forcing works well for me. Just set the [delwrite~] to 10 (and
>>> [delread~] to 0) in your patch and the number box shows 0 (this means
>>> zero delay, right?).
>>>
>>> Roman
>>>
>>>
>>> _______________________________________________
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151212/205925b4/attachment.html>