- changed title to Some crash/freeze potential because some potentially illegal stuff is done in audio thread
Some crash/freeze potential because some potentially illegal stuff is done in audio thread
Issue #35
resolved
This is easy to fix actually. All the target value modifications need to happen in the main thread anyway (something that was not obvious in the beginning of the development). So we can defer code execution to the main thread a bit sooner in the processing chain. Should not have any performance penalty. On the contrary, it should improve performance and relieve the audio thread.
Comments (4)
-
reporter -
reporter - edited description
-
reporter re
#34Don't freeze when writing send volume automation while FX multiprocessing enabled re#35Improve stability by deferring to main thread much earlier re#31Remove clever max jump tracking logic because with the new threading model it's not necessary anymore→ <<cset 1b6916ad95dc>>
-
reporter - changed status to resolved
- Log in to comment