OK, I will try to explain:
The "multiplier" code was considered and tested, and it was bad. It doesn't allow you to get good speed and having the precision one-step movement. The used code is developed (I wrote a tens of various algorithms for encoders since 2012, one was worked in ArdSimX pretty fine and suits most needs for ArdSimX, but not SimVim), and this algorithm allows to have any speed and fine precision at the same time.
- Case 1: The encoder state reading program is used this simple "direct" way -" read the state -> send the state to the plugin". NOTE: assume it is a stand-alone code, for reading encoder only (no other hundreds of input, no outputs), etc.
In this case the firmware fix the next encoder state change and activates the "send to plugin" protocol.
The plugin can receive this one change in the same moment, but most likely with some delay defined by X-Plane FPS.
Why? Because the X-Plane (any plugin) can send or receive data only in the end (or start) of the X-Plane work cycle.
If the FPS = 40 for example, the plugin can receive next change only after 25 ms.
You cannot to exchange data between plugin and external controller faster than X-Plane frame rate,
That's mean that if you will rotate the encoder a bit faster the plugin will not receive every step.
- Case 2: The firmware program reads and saves cumulative state changes in every X-Plane frame, then sent the data as number of increment steps for the plugin. This will work better, but don't allow you to accelerate the movement. The problem is, to make it work in massive data exchange system, with various encoder types, system speed and synchronization.
Case 3 (the SimVim protocol):
As you cannot to exchange data between plugin and external controller faster than X-Plane frame rate, the firmware program monitors every encoder state change between frames (along with hundreds of other inputs), count them as in case2, but with additional function to calculate speed, acceleration, depending on X-Plane frame rate and controller loop time.