a free alternative to Bome that might do the trick also is Transmidifier. Bome has the advantage in that it can also listen for keyboard commands if that is something you need.
Another free tool that might work for this is MidiPipe.
Thanks ! I'll check them out.
The original reason why I got Bome is that it does virtual MIDI ports. But it can do maximum five of them, which is still a bit short for my needs.
Interesting that its using PitchBend messages to move the fader...I would be curious to see a log of those messages to see if we can spot why it judders.
Pitchbend has a better resolution than CC. I can't remember how many bits, but surely more than 7. It's coded over two bytes.
As for the MIDI log, it's on another computer, and mine doesn't log timing. But I can tell you what I saw (We're talking messages from the DAW to the controller) :
Pitchbend/fader messages are not outcrowded by other messages (like display etc.), contrarily to what MFF's documentation suggests. In fact, Reaper only sends bulk updates every couple of seconds, and we're only talking about a handful of messages each time (when it runs, of course there's the song position or timecode display to update too, but that too is minimal load).
The problem is pitchbend/fader messages are just too few to express a smooth movement. Indeed, Reaper sends a fader update every 15ms, though this can be configured. (I'm baffled: What's the point of having such a good bit resolution if you're gonna skip most steps anyway???)
MFF is supposed to interpolate what's missing, but it's just making the jerkiness even worse: More messages but still not enough for a smooth movement. Increasing the fader update frequency in Reaper should do the trick as well, but there's a limit to what a computer can do in real time. I don't suppose I could get intervals shorter than my shortest clean audio buffer size, for example, and it's about the same order of timeframe. Plus, my system isn't terribly efficient that way, I must confess. It used to be, but some cleaning is overdue.
I think the only way I could possibly improve the situation would be to tweak my system for best realtime performance (lowest possible latencies), which is something I've been planning to do for over a year now.
But of course, that's only assuming the motors are capable of smooth operation at all. After all, no matter how finely grained, the data stream will always be discrete by nature. I naively thought it was the control surface's job to smooth it out. Apparently I was wrong. It's the computer's job... as if it had nothing better to do !
So, for now, the ability to switch the motors on and off at will is still a good enough workaround. I turn them on when working on the general balance (because they're still convenient for that), and off when actually automating the mix.