<div dir="ltr">> <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><div><span style="font-size:12.8px">but weirdness arises from 0 length delay.</span></div><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 class="" 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><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><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 class="" 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><div><span style="font-size:12.8px">don't work for block size < 64</span></div><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 class="" 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><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><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><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">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><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 class=""><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 class="HOEnZb"><font color="#888888"><br>
Roman<br>
<br>
</font></span><br>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">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>