Yep, took a quick look and would agree with joule that it the code most likely could be simplified quite a bit.
First of all, you seem to be iterating through, and doing a lot of logic, for each of the attached parameters.
But, you hardly need that, do you? I mean, the focus should be on dealing with when and if a parameter has changed? So I would try to make a restructuring with that in mind.
Usually, the rule for optimization says “don’t do it / do it later”. But with this kind of real-time critical tool I would definitely try to make the core logic as focused as possible - because, automation recording doesn’t suddenly bring 10.000 points to the table, you more-or-less have a steady stream of values that you need to deal with.
Trying to do things asap will also make it clear if the tool is actually able to perform it’s job in realtime. The incoming “value-has-changed” notifications are fired in near-realtime, and it’s important to respond to them if you want to determine the fractional time - so I wouldn’t use any timers (idle or otherwise) at all. Only when and if the tool is not able to deal with the messages as they arrive should “delayed writing” be something to consider.
PS: This is perhaps a slightly different subject, but while maintaining Duplex, I’ve found that some MIDI controllers fire many times more messages than others - including repeating the same message/value multiple times, due to a discrepancy between the resolution of the physical knobs and the values it was transmitting. I had to implement throttling to control the volume of incoming messages.