<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">And I think the same logic will apply to any [delread~] buffer explicitly set to <= 60 samples ([delread~] rounds up from the input to the nearest multiple of 4).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 12, 2015 at 4:49 PM, Matt Barber <span dir="ltr"><<a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">There's one trick that works for zero delay and [delwrite~ 0], based on the code of [delread~]: provide a negative delay time (with abs(delay time) > 1 sample).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Here's what's going on in Alexandre's patch.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">[delwrite~ 0] sets up a buffer that is 68 samples long, plus four extra for interpolation in [vd~], which we needn't worry about here.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">delwrite's float method is this:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">/*---------------------------------------------------------------------------*/</div><div class="gmail_default" style="font-family:verdana,sans-serif"><div class="gmail_default">static void sigdelread_float(t_sigdelread *x, t_float f)</div><div class="gmail_default">{</div><div class="gmail_default"> int samps;</div><div class="gmail_default"> t_sigdelwrite *delwriter =</div><div class="gmail_default"> (t_sigdelwrite *)pd_findbyclass(x->x_sym, sigdelwrite_class);</div><div class="gmail_default"> x->x_deltime = f;</div><div class="gmail_default"> if (delwriter)</div><div class="gmail_default"> {</div><div class="gmail_default"> int delsize = delwriter->x_cspace.c_n;</div><div class="gmail_default"> x->x_delsamps = (int)(0.5 + x->x_sr * x->x_deltime)</div><div class="gmail_default"> + x->x_n - x->x_zerodel;</div><div class="gmail_default"> if (x->x_delsamps < x->x_n) x->x_delsamps = x->x_n;</div><div class="gmail_default"> else if (x->x_delsamps > delwriter->x_cspace.c_n - DEFDELVS)</div><div class="gmail_default"> x->x_delsamps = delwriter->x_cspace.c_n - DEFDELVS;</div><div class="gmail_default"> }</div><div class="gmail_default">}</div><div class="gmail_default">/*---------------------------------------------------------------------------*/<br></div><div class="gmail_default"><br></div><div class="gmail_default">Here, I believe that because the write and read are sorted, x->x_zerodel == 0. Also DEFDELVS == 64, and delwriter->x_cspace.c_n == 68;</div><div class="gmail_default">So with [delread~ 0], x->x_delsamps is initialized to 0 + 64 - 0. The first if statement fails, but the second one passes, and x_delsamps is set to c_n - DEFDELVS = 4.</div><div class="gmail_default"><br></div><div class="gmail_default">Let's pick it up after [delwrite~]'s second block calculation. It's just gotten the range 64:127 in its input vector, and written indices 64:67 with 64:67, and indices 0:59 with 68:127. Its phase is now at index 60. With x_delsamps set to 4, [delread~ 0] begins reading at index 60-4 = 56, which contains the value 124. For four samples, the difference between input and output (the [-~] in the patch) is -60. Indices 60:67 contain values 60:67, and 0:59 contain 68:127; the difference between input and output is therefore 8 for the 60 remaining samples of the block. Hence the oscillation between 8 and 60 in the number box, with 8 appearing most of the time.</div><div class="gmail_default"><br></div><div class="gmail_default">If you set a negative delay, the first if statement passes, and x_delsamps is set to 64, as it should be to get zero delay (that is, it's reading the last 64 samples written to the delay buffer, so there's zero difference between input and output).</div><span class="HOEnZb"><font color="#888888"><div class="gmail_default"><br></div><div class="gmail_default">Matt</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div></font></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 12, 2015 at 12:00 PM, Alexandre Torres Porres <span dir="ltr"><<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>> <span style="font-size:12.8px">Order forcing works well for me. Just set the [delwrite~] to 10 (</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">but weirdness arises from 0 length delay.</span></div><span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">If a </span><span style="font-size:12.8px;background-color:rgb(255,255,255)">delay</span><span style="font-size:12.8px"> of zero WAS actually permitted, these would form infinite loops. </span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">Don't think so, depends on what a 0 delay is. If it is "no delay", and by that I mean "No Buffer", then it only outputs 0 values, right?. In other words, nothing happens, no infinite loop, nothing, just zeros...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">but if instead of zeros it does have some buffer length in it, then a feedback delay will always de delayed at least one block size, so no worries about feedback loop. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Actually, you need to set delread to "0" for a minimum block size delay. Perhaps you meant you couldn't or shouldn't put a "0" delay time in the delread~ object for feedback, but actually you NEED to do that.<br><br>Thing is that I just use delwrite~ and delread~ with 0 length arguments for both and a block size of 1 to allow single sample feedback. I do it cause I wanted the minimum delay buffer size as possible and I didn't want to write in tiny and long and boring numbers according to one sample size depending on sample rate.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Since it was working, I had just always assumed it would create a buffer of one block.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This is not what's really happening as I see it. <br><br>I don't really care that much on what happens, doesn't seem like a big deal, but it was nice to understand this behaviour. It doesn't seem very consistent, that's all I can say...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Now, what it actually does is really just a matter of design choices. It could very much just create no delay buffer at all, where you'd get 0 values perhaps, like I imagined. That's silly anyway...<br><br>Or... it could be only one sample... or one block... I had assumed out of nowhere that it could be a block size, but it could much be just a single sample, which seems to make sense and it'd be cool I guess.<br><br>What's really bad is that you need to always put a value that is at least one block size. It's a bug considering </span><span style="font-size:12.8px">the documentation clearly stated that the design was really supposed to be a delay between 0 and max delay size, but one way or another, </span><span style="font-size:12.8px">it's really annoying doing all this math as a workaround, when it's just a matter of coding it properly to allow any size greater than 0 and smaller than a block size (in orther words, to fix it).</span></div><span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">If you, however, want a simple block </span><span style="font-size:12.8px;background-color:rgb(255,255,255)">delay</span><span style="font-size:12.8px"> in a feedback loop,</span></div><div><span style="font-size:12.8px">> just use a pair of [send~] and [receive~].</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">don't work for block size < 64</span></div><span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">specifying the buffer size makes much more</span></div><div><span style="font-size:12.8px">> sense then giving a maximum </span><span style="font-size:12.8px;background-color:rgb(255,255,255)">delay</span><span style="font-size:12.8px"> time</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">Those two things means the same to me, where maximum delay time = buffer size. I don't get this.</span></div><span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">[delwrite~] object would need to keep track of this</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">sure, whatever, why not?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">by the way, that's the one that defines the max delay length (or buffer size), (and there can be only one, by the way) - so it only needs to keep track of its block size to work out the proper buffer size. <br><br>I might see an issue if delread~ is in a subpatch that has a longer block size, but I don't wee why anyone would need that, and perhaps just say you shouldn't do it. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I think we've discussed this before, perhaps just make sure both are in the same block size. I for one, never needed them to be in different block sizes, makes no useful sense. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">But anyway, I guess Miller is the one that should hop in and share his thoughts.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">and lets not forget the "clear" method, also important :)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">cheers</span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>2015-12-12 12:33 GMT-02:00 Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><span><br>
On Fri, 2015-12-11 at 14:26 -0200, Alexandre Torres Porres wrote:<br>
> hi, I'm checking that if you put a 0 length delay in delwrite~ you<br>
> still have some buffer<br>
><br>
><br>
> what's up with that? and how does it work? how big is it when you<br>
> don't define it?<br>
<br>
</span>Don't know. I confirm that weirdness happens when setting [delwrite~] to<br>
0. In other words: The only value that does not justify using a delay at<br>
all shows unexpected behavior. I can live with that.<br>
<span><br>
> I always get a minimum dealy even with order forcing (and different<br>
> values depending on extended orvanilla), it seems the delay needs to<br>
> be at least the block size to work properly<br>
><br>
><br>
> moreover, I can't have an order forcing<br>
<br>
</span>Order forcing works well for me. Just set the [delwrite~] to 10 (and<br>
[delread~] to 0) in your patch and the number box shows 0 (this means<br>
zero delay, right?).<br>
<span><font color="#888888"><br>
Roman<br>
<br>
</font></span><br></div></div><span>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>