[PD] 0 length delay in delwrite~

[Alexandre Torres Porres]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151213/3e209768/attachment-0001.html>