> 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 <[email protected]>: > > 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" <[email protected]> > An: "Christof Ressi" <[email protected]> > Cc: "Miller Puckette" <[email protected]>, "[email protected]" > <[email protected]> > 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 <[email protected]>:> 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" <[email protected][[email protected]]> > An: "Christof Ressi" <[email protected][[email protected]]> > Cc: "Miller Puckette" <[email protected][[email protected]]>, > "[email protected][[email protected]]" <[email protected][ > [email protected]]> > 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 >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
