[PD] 0 length delay in delwrite~

[Alexandre Torres Porres]

> So I'm quite astonished that you're accusing me of throwing
> around with apodictic statements

you're right, I was too harsh

sorry

2015-12-13 16:37 GMT-02:00 Christof Ressi <christof.ressi at gmx.at>:

> > just think outside your mind a little, think about other people that are
> not you...
>
> I'm just giving my personal opinion. I can understand that you want to
> have more things working 'under the hood' and I'm in the opposite camp. But
> that's fine and as always the truth lies in the middle. If Miller decides
> that [delwrite~] should check for the block sizes of all the [delread]
> objects, that's perfectly fine for me.
> No matter how stuff is implemented, the most important thing is that it's
> fully documented. I agree that Pd should be as accessible as possible, but
> that's mostly a matter of documentation.
>
>
> > why would you insist in saying things are unnecessary just because you
> don't mind doing it
>
> I'm giving personal opinions and I'm clearly marking them as such (adding
> phrases like "I think", "in my opinion"). So I'm quite astonished that
> you're accusing me of throwing around with apodictic statements.
>
>
>
>
>
>
>
>
> Gesendet: Sonntag, 13. Dezember 2015 um 19:09 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: Re: [PD] 0 length delay in delwrite~
>
> 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[porres at gmail.com]>
> An: "Christof Ressi" <christof.ressi at gmx.at[christof.ressi at gmx.at]>
> Cc: "Miller Puckette" <mpuckett at imusic1.ucsd.edu[mpuckett at imusic1.ucsd.edu]>,
> "pd-list at lists.iem.at[pd-list at lists.iem.at]" <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/5ac9a721/attachment-0001.html>