<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-09-22 15:41 GMT-03:00 IOhannes m zmölnig <span dir="ltr"><<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">this seems to be the easy route, just as [s~]/[r~] or [throw~]/[catch~]:<br>
simply forbid the use of [delread~]/[vd~] if the block-sizes differ.<br></blockquote><div><br></div><div>I think it's an elegant solution, and can't see why it would be a problem. But then, I was suggesting it because Christof was pointing how</div><div><br></div><div><span style="color:rgb(80,0,80);font-family:Verdana;font-size:12px">"it would have to keep track of ALL the objects reading from the buffer and the individual blocksizes they are operating at. Which would be highly inefficient and give no practical benefit."</span><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">or forbid any use of [delread~]/[vd~] if the block-size is not 64 (which<br>
is really  the behaviour of [s~]/[r~])<br></blockquote><div><br></div><div>now that's bad, because it'd ruin the usage of delay lines in FFT patches, like spectral delays or the phase vocoder patch I'm working on.</div><div><br></div><div>cheers</div></div></div></div>