Repeatable hang
Issue #25
resolved
In the course of making a silly mistake, I've found a way of making it beachball by sending a negative parameter to both fl.interval~ and fl.count~ at the same time.
Comments (5)
-
repo owner
-
repo owner
Crash fixed. Hang debates to come later.
-
repo owner
OK - so I now have a basic mechanism that allows the DSP to time out. At the moment if you spend 10 seconds or more in a single audio call then it should time out. That seems to me to strike a reasonable balance between realtime requirements and the need for timeout to be relatively speedy - I'd be happy to make it variable in the long run, but that's a bit more work. I also need error reporting to make this nicer, but that is on the way.
Thoughts?
-
repo owner
Oh - and once it's timed out that context (which probably means all the frame lib stuff in a patch) switches off until it is reset.
-
repo owner
- changed status to resolved
Right - this is fixed in the next one - now down to 5 seconds.
- Log in to comment
The fl.count~ is only important in that it is preventing the crash.
The crash is quite concerning, as this is a scheduling arrangement that is problematic (I'm not sure yet if it has any actual use, but it still shouldn't have unexpected behaviour).
The hang is more complex. I'll need to have a think about what to do in this kind of scenario.