I would think the best approach would be to actually limit the
accepted frequency, and not access NaN for example.
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 :¬).
But for a
watchdog-style approach, I bet it wouldn't be difficult to implement
an "abort" flag in each shred that can be set to 1, and gets checked
between sample computations. Not sure how it's done now, perhaps
something similar.
Yes, I was thinking along those lines as well.
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.
I also wonder how different things are if we supply .freq() functions with values that are merely very, very high instead of being infinity.
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.
Yours,
Kas.