BUG agreed
It works with the DN because it doesn’t have an issue that the ST has ended up with.
The DN has a similar filter to those of the ST digital tracks.
They both have NRPN control of the fine tuning of e.g. Filter freq
The DN also has a separate CC for fine control of the freq, the ST does not.
I explained elsewhere how an NRPN string is formed, but this is not about NRPN, but by utilising a CC pair you can have a similar control - so the CC MSB(coarse) and CC LSB(fine) are sent in a coordinated way as a pair of CCs where there will be fine changes within each integer step
This is achieved by sending the coarse, followed by the current updated fine value, but the fine value CC is a different identity - the OT learns the coarse value, so it doesn’t process or care about the fine CC coming at it too
So DN works …
The ST falls over because it appears to have inherited code from the DN which packages up the distribution of the fine LSB CC, except that … there isn’t one allocated … so it’s got this default (or error assignment) of the MSB CC(coarse)
So when you are turning the ST Filter freq (and other parameters elsewhere perhaps), but let’s stick with Filter Freq CC on a digital track, it is sending for each change (including on fine changes where it has no assignment) on the device
Coarse CC 74 and spuriously ‘fine’ CC 74
so every step you take up the fine ladder on the device, the OT is echoing back through the bi-directional MIDI the CC 74 value you were on as you start ascending between an integer step, basically all of your fine increments are dragging you back to the coarse integer step below it.
The bug is that it is distributing these spurious extra CC messages between steps, they are utterly redundant and wastefully hog the MIDI bus, and when you are using teh OT in your way it is manifesting in this issue - (you only need to activate the respective OT midi channel to illustrate this, no need even to learn CCs - i use Channel 16 at each end to keep things simpler)
So the bug is that ST will send a spurious LSB fine message exactly equivalent to the current MSB coarse CC, 74 in this case !
In the real world without bi-directional MIDI this is wrong, but benign at the expense of over-defining the steps on the stair, so some have not noticed it - you have noticed it, because when the OT gets barraged by the same CC message as you try to ramp up the fine, it keeps dragging you back - you can only accelerate through teh values to get through it. But this is definitely a BUG, the (re-used?) code to send CC LSB data is not viable as there is no CC LSB number (won’t be any free) to send (see table) - the NRPN side can validly use fine control (a different string of packaged CCs), but this CC LSB should be disabled when the output is CC for any parameters which do not have a CC LSB assignment.
That’s the issue.