<div dir="ltr">Stephen;<span dir="ltr"></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I would think the best approach would be to actually limit the<br>
accepted frequency, and not access NaN for example. </blockquote><div><br>That would be good, but it would go at the expense of our options in controlled aliasing, a technique that may have valuable artistic uses to some. It could still be a good trade here. I like the NaN idea in any case, I don't think we can expect Wurley to deal with "inf", even if it *is* a float :¬).<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> But for a<br>
watchdog-style approach, I bet it wouldn't be difficult to implement<br>
an "abort" flag in each shred that can be set to 1, and gets checked<br>
between sample computations. Not sure how it's done now, perhaps<br>
something similar.<br>
</blockquote><div><br>Yes, I was thinking along those lines as well.<br><br>ChucK is too large and complicated to avoid the possibility of things going wrong and as we say; "powertools can maim" but I don't like stuff bringing down the whole VM. Right now, for example, a integer div. by 0 will take out the whole VM without any comment which I think is a bit much. Dropping that shred seems far more reasonable.<br>
<br>I also wonder how different things are if we supply .freq() functions with values that are merely very, very high instead of being infinity.<br><br>Right. I feel this responce to "inf" as a frequency parameter is sufficiently bothersome to call it a issue for the bug page. I'll add it there and if somebody disagrees we can take it off again.<br>
<br>Yours,<br>Kas.<br></div></div><br></div>