Both problems should be fixed in the
latest development preview!
Detailed explanations for the curious:
SQLite: After an hour of going through their old versions, narrowing down where the bad behavior started (and tracking down and back-porting a separate crash fix in their code), I found it. SQLite 3.8.0 introduced their "Next Generation Query Parser" which is apparently 100x slower in Synthesia's case. I
found the magic, one-line incantation I needed to make it fast again.
Slow-down without built-in synth: This one was even more interesting! The slow-down
isn't fixed by using Microsoft's synth. But (if you happen to have it installed), it is fixed "permanently" by enabling VirtualMIDISynth, even if you disable it afterward. That seemed extra strange to me, and I noticed that if you closed the little system tray icon that it launches,
then it would slow back down.
But now we've got a situation that doesn't even involve Synthesia that is changing its performance! As a test, I tore out 100% of Synthesia's MIDI device code (so the device lists appear completely empty) and it was
still slow! Then, separately, from the Start Menu, I launched VirtualMIDISynth and Synthesia sped up!
Of course it ended up being an
undocumented, breaking change made by Microsoft in Windows 10 version 2004. Our built-in synth (based on the lovely BASS and BASSMIDI libraries) happened to be requesting a faster timer on Synthesia's behalf. When the built-in synth is disabled, no such request was being made anymore. In the past this never mattered because
something in the system had always requested the fastest timer. Since Windows 10 2004 we have to do it ourselves.
Technically this has always been my fault for not calling
timeBeginPeriod when the app starts.
In any event, thanks for the detailed bug reports and work-arounds!