fl.join~ crash
Issue #69
resolved
I've been able to reproduce a crash while I was making the fl.join~ help file. I'm not sure if fl.join~ is the culprit but the crash log points to some sort of host desync. I've attached the the patch and posted the log to pastebin as I can only attach one file. Just turn audio on and wait for about 1 second.
Comments (7)
-
repo owner
-
Account Deleted reporter
So if you keep it in samples (no matter how the two schedulers are related) does it work?
-
Account Deleted reporter
I also tried changing the trigger inlets to only the left one but it still crashed if that helps you narrow it down.
-
repo owner
Thanks so much for finding this one - a really good catch, and quite surprising. The error was due to a lack of a != comparison operator for the fixed point time format. There is (however), a conversion from this format to a double, so when comparing two time values for inequality they were being converted to doubles, leading to a case here where two values appear equal that are not, and then the scheduling algorithm does not operate correctly. This situation in itself is a byproduct of the imprecision in converting times in milliseconds (which I will fix shortly), so it could easily not have become apparent.
I've pushed the fix for the first bug - if you have time to build and verify that it is fixed (using the testing or development builds) that would be handy, as once I've fixed the conversion the patch wouldn't crash anyway.
-
Account Deleted reporter
Will build today as I want to finish the reference for fl.join~
-
Account Deleted reporter
New build works for me.
-
repo owner
- changed status to resolved
- Log in to comment
Thanks - this one is a complex one that seems to involve a couple of different elements that I can't yet disentangle - none of them are the fl.join~ - it's to do with a certain dependency structure (the fl.join~ here is dependent on the two schedulers and also another object that is also dependent on the two schedulers). Something about that and possibly some details of the time format is creating a problem.
The reason to suspect the time format, is that if I specify 44100 samples in the left then I get no crash - turns out the internal calculation is giving a slightly different number - that's sort of a separate (accuracy) bug, but it should work either way...