[PD] 0 length delay in delwrite~

[Matt Barber]

The docs are right in one sense (at least for block = 64), but probably
misleading: min delay possible is zero, but to get zero delay [delwrite~]
needs to compute before [delread~]. Max delay is given in [delwrite~], but
to attain the max delay, [delread~] needs to compute before [delwrite~].
There's a symmetry to it.

The piece of code I can't figure out is this. When the buffer is allocated,
it actually does add 64 samples to the size:

/*--------------------------------------------------------------*/
    int nsamps = x->x_deltime * sr * (t_float)(0.001f);
    if (nsamps < 1) nsamps = 1;
    nsamps += ((- nsamps) & (SAMPBLK - 1));
    nsamps += DEFDELVS; /*DEFDLVS == 64/*
/*--------------------------------------------------------------*/

But when you set the delay in [delread~], it clips the size of the buffer
to (size - 64 == buffer size specified in [delwrite~]):


/*--------------------------------------------------------------*/
        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;
/*--------------------------------------------------------------*/


I don't have time to puzzle through this right now, but I'm not sure what
DEFDELVS is actually designed to do.

On Sun, Dec 13, 2015 at 1:09 PM, Alexandre Torres Porres <porres at gmail.com>
wrote:

> Well, it's just a matter of opinion, you think it's unnecessary and I
> couldn't disagree more, we could just get it over with :)
>
> But tell me, deep inside, if it did just work without you bothering with
> anything, would that be a problem to you? Cause it'd be a huge relief for
> me...
>
> It's not even for me, I guess I could live with that, but I teach Pd for
> almost a decade now, I know something about newcomers... I'm an advocate of
> Pd and I try to make it as accessible and easy as possible, and I'd really
> have a problem with telling them (well, you gotta worry about all this
> stuff because there is a mentality in the Pd world that it'd be
> "unnecessary" for this to be automatically worked out for the user).
>
> My life in Pd world is mostly devoted to teaching and advocating Pd as an
> user friendly tool, it has this power...
>
> just think outside your mind a little, think about other people that are
> not you... why would you insist in saying things are unnecessary just
> because you don't mind doing it - do you mind *not* doing it? What would
> you lose? Why making a case out of it?
>
> well, again, in the end, it's a matter of opinion, but as a tie-breaking
> criteria, I think that making it easier for more people and more user
> friendly should count.
>
> cheers
>
> 2015-12-13 15:54 GMT-02:00 Christof Ressi <christof.ressi at gmx.at>:
>
>> >  add a bunch of samples to the delay ; work that internally
>>
>> In a way, I agree on that, just add 64 samples so everything works for
>> trivial use cases at block size 64. If you're using delay lines with other
>> block sizes you're doing advanced stuff anyway.
>>
>> > why live so hard?
>>
>> Given that everything is documented cleanly, there's no higher math
>> involved in getting the right buffer size, just a multiplication and a
>> subtraction ;-).
>>
>>
>> > That doesn't seem crazy, get them all, check their block size, stay
>> with the greater block size, work it out interbally, voilà...
>> > all the worries are over. Not too crazy and just elegant simple coding.
>> You're treating this as a mission impossible where it's quite trivial to me.
>>
>> I never said it's a mission impossible. I just said it's unnecessary. If
>> [delwrite~] has fixed buffer size, why should it constantly change only
>> because I change the block size in some subpatch? To me this sounds rather
>> absurd. It's not like that we don't have to care about a lot things on our
>> own (just think of fft subpatches!).
>>
>>
>>
>>
>>
>>
>>
>> Gesendet: Sonntag, 13. Dezember 2015 um 18:34 Uhr
>> Von: "Alexandre Torres Porres" <porres at gmail.com>
>> An: "Christof Ressi" <christof.ressi at gmx.at>
>> Cc: "Miller Puckette" <mpuckett at imusic1.ucsd.edu>, "pd-list at lists.iem.at"
>> <pd-list at lists.iem.at>
>> Betreff: Re: Re: Re: [PD] 0 length delay in delwrite~
>>
>> > At least we all agree that there's a mismatch between
>> > the docs and the actual behaviour.
>>
>> that's a start
>>
>>
>> In my opinion, being able to use [delwrite~] and [delread~] at different
>> blocksizes is a nice feature, so what about a nice little warning in the
>> docs that you have to care about the buffer size if you're using different
>> blocksizes?
>>
>> Even failing to see how one thing prevents the other, my point is that
>> you need to care about buffer size ALL OF THE TIME... it's never Good.
>>
>> And in my point of view, it's just so simple: add a bunch of samples to
>> the delay ; work that internally
>>
>> Of course Miller could add some complicated mechanism for [delwrite~] to
>> keep track of all the block sizes of its [delread~] objects.
>>
>> That doesn't seem crazy, get them all, check their block size, stay with
>> the greater block size, work it out interbally, voilà... all the worries
>> are over. Not too crazy and just elegant simple coding. You're treating
>> this as a mission impossible where it's quite trivial to me.
>>  , but to me the simplest solution is updating the docs and stating:
>> "max. delay time = buffer size - block size of [delread~]"
>>
>> Might be "simpler", but the craziest, and also the laziest, turning the
>> user and patching experience into a nightmare. You're asking us to check
>> all the block sizes and do the math ourselves and then convert it to ms and
>> then insert it into a delwrite~ object... why live so hard?
>>
>> cheers
>>
>
>
> _______________________________________________
> 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/20151213/0bbf954b/attachment-0001.html>