To make things more complicated, [vd~] behaves differently, it keeps the extra 64 samples. see the attached patch.
Gesendet: Sonntag, 13. Dezember 2015 um 20:35 Uhr Von: "Matt Barber" <[email protected]> An: "Alexandre Torres Porres" <[email protected]> Cc: "Christof Ressi" <[email protected]>, "[email protected]" <[email protected]> Betreff: Re: [PD] 0 length delay in delwrite~ 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 <[email protected]> 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 <[email protected][[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][[email protected]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]
#N canvas 578 312 831 458 10; #N canvas 0 50 450 300 write 0; #X obj 123 47 inlet~; #X obj 122 142 outlet~; #X obj 123 78 delwrite~ test1 5.8; #X connect 0 0 2 0; #X restore 89 145 pd write; #N canvas 0 50 450 300 read 0; #X obj 125 77 inlet~; #X obj 124 129 delread~ test1; #X obj 229 84 r test1-ms; #X obj 124 151 outlet~; #X connect 1 0 3 0; #X connect 2 0 1 0; #X restore 89 179 pd read; #N canvas 0 50 450 300 write 0; #X obj 123 47 inlet~; #X obj 122 142 outlet~; #X obj 123 78 delwrite~ test2 5.8; #X connect 0 0 2 0; #X restore 173 146 pd write; #N canvas 0 50 450 300 read 0; #X obj 125 77 inlet~; #X obj 124 151 outlet~; #X obj 229 84 r test2-ms; #X obj 125 128 vd~ test2; #X connect 2 0 3 0; #X connect 3 0 1 0; #X restore 173 180 pd read; #N canvas 0 50 450 250 (subpatch) 0; #X array array1 256 float 3; #A 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.984883 0.969766 0.954649 0.939531 0.924414 0.909297 0.89418 0.879063 0.863946 0.848828 0.833711 0.818594 0.803477 0.78836 0.773243 0.758125 0.743008 0.727891 0.712774 0.697657 0.68254 0.667423 0.652305 0.637188 0.622071 0.606954 0.591837 0.57672 0.561602 0.546485 0.531368 0.516251 0.501134 0.486017 0.470899 0.455782 0.440665 0.425548 0.410431 0.395314 0.380197 0.365079 0.349962 0.334845 0.319728 0.304611 0.289494 0.274376 0.259259 0.244142 0.229025 0.213908 0.198791 0.183673 0.168556 0.153439 0.138322 0.123205 0.108088 0.0929705 0.0778534 0.0627362 0.047619 0.0325019; #X coords 0 1 256 -1 200 140 1 0 0; #X restore 303 32 graph; #N canvas 0 50 450 250 (subpatch) 0; #X array array2 256 float 3; #A 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1.05575e-006 0.98488 0.969766 0.954649 0.939531 0.924414 0.909297 0.89418 0.879063 0.863946 0.848828 0.833711 0.818594 0.803477 0.78836 0.773243 0.758126 0.743008 0.727891 0.712774 0.697657 0.68254 0.667423 0.652305 0.637188 0.622071 0.606954 0.591837 0.57672 0.561602 0.546485 0.531368 0.516251 0.501134 0.486017 0.4709 0.455782 0.440665 0.425548 0.410431 0.395314 0.380197 0.365079 0.349962; #X coords 0 1 256 -1 200 140 1 0 0; #X restore 305 195 graph; #X obj 93 50 s test1-ms; #X obj 183 49 s test2-ms; #X floatatom 92 6 5 0 0 0 - - -, f 5; #X floatatom 182 7 5 0 0 0 - - -, f 5; #X obj 91 261 tabwrite~ array1; #X obj 171 298 tabwrite~ array2; #X obj 128 116 vline~; #X msg 126 84 1 \, 0 1.5; #X obj 69 80 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 93 26 / 44.1; #X obj 184 26 / 44.1; #X text 69 354 buffer size is 256 samples for both delay lines; #X text 80 -18 delay time in samples; #X text 70 380 notice how delread~ starts to clip at 192 while vd~ goes up to 256; #X text 31 55 click!; #X obj 302 -34 loadbang; #X msg 301 -11 \; pd dsp 1; #X connect 0 0 1 0; #X connect 1 0 10 0; #X connect 2 0 3 0; #X connect 3 0 11 0; #X connect 8 0 15 0; #X connect 9 0 16 0; #X connect 12 0 0 0; #X connect 12 0 2 0; #X connect 13 0 12 0; #X connect 14 0 13 0; #X connect 14 0 10 0; #X connect 14 0 11 0; #X connect 15 0 6 0; #X connect 16 0 7 0; #X connect 21 0 22 0;
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
