Really sorry to be so persistent. I just realized that I never shared how I actually came to the conclusion that the bottleneck is somewhere in the E1 Lua API and not somewhere else (MIDI transmission, my plugin, my E1 script itself). So this is not to demonstrate that there is a bottleneck, but to show where the bottleneck is probably located:
- Use this alternate preset which is functionally identical with the main version but skips all calls to the E1’s Lua API (more specific it’s set* calls)
- Compare the performance with any of the repro cases I shared above
- Monitor the USB/MIDI activity while reproducing the slowdown
- Note how instead of the device freezing for several seconds, the script is mostly finished when I change my eye’s focus from my computer screen to the E1, at max rarely half a second later
- To verify what noted in step 4, also immediately wiggle the knobs to check the device is indeed responsive
The fact that skipping all E1’s Lua set API calls fixes these slowdowns suggests that it’s caused by a set of functions’ implementations on the E1’s Lua API.