Feature Request: Reduce stuttering/noise on X-Touch sliders when automated

[higginsdragon]

Just putting this here to keep track of and discuss.

A very common complaint that I've seen with the X-Touch is how noisy the sliders are when they're adjusted. This could be fixed in firmware but Behringer seems uninterested in fixing it.

It can be fixed in software, here's a good discussion I found with a couple solutions including one in another X32 repo:
https://community.musictribe.com/discussion/solutions/10/0/253426/faders's-stuttering-and-so-very-noisy-when-reading-volume-automation

Both solutions involve interpolating the data from Reaper before sending it off to the X-Touch. I got the C++ code for one of them, the X32 repo is C but it could be adapted with some work.

[FunkybotsEvilTwin]

@higginsdragon, if you do end up pursuing this, there's one more issue with X-Touch faders. They're not full 14Bit! The max MSB/LSB bytes are 7c 7f instead of 7f 7f, which is 15935, not the full 14-bit max of 16383. So when normalizing to 0.0–1.0 for things like plugin parameters, they don't max out 1.0 as expected.

We had a couple of users validate this behavior across X-Touch devices, so it's not just one wonky miscalibrated fader or something but something in the actual X-Touch firmware.

If you're building a dedicated X-Touch fader widget or feedback processor, it may be worth compensating for this so they behave like proper 14-bit faders and hit 1.0 when they should.

Here's a small (untested) idea that could potentially be dropped into handy_reaper_functions.h to handle normalizing for the X-Touch (and/or X32):

static double xTouch14BitToNormalized(unsigned char msb, unsigned char lsb)
{
    // Behringer X-Touch max value is 0x7C7F (15935), not full 14-bit (16383)
    int val = lsb | (msb << 7);
    double normalizedVal = val / 15935.0;

    normalizedVal = normalizedVal < 0.0 ? 0.0 : normalizedVal;
    normalizedVal = normalizedVal > 1.0 ? 1.0 : normalizedVal;

    return normalizedVal;
}

static int normalizedToXTouch14Bit(double val)
{
    if (val < 0.0) val = 0.0;
    if (val > 1.0) val = 1.0;

    int scaled = static_cast<int>(val * 15935.0 + 0.5); // round to nearest
    return scaled;
}

[rwallingford]

I have implemented scaling of of X32 faders. in "...OSC_Widgets.h", as the X32 has 4 nodes where scaling changes. This scaling code makes X32 faders match reaper faders +- 0.2 db, whicis much better than the unscaled at +- 5%
Note this is specific to the X32 series, not the Xtouch.

This required a feedback processor called "X32"

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class OSC_X32FaderFeedbackProcessor : public OSC_FeedbackProcessor
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

It would be much better to the XTouch fader scaling encapsulated like that.
Fits the CSI paradigm.

As I have plenty of free time tonight, I will attempt to code this up and test it.

[FunkybotsEvilTwin]

Sounds great Roy! Thanks!

[rwallingford]

Making good headway on this, but the XTouch physical faders seem to limit their MIDI message throws to a max of about +7 or or so above both the maximum and minimum throws..
Maybe a limitation by Berhinger to prevent faders from slamming against metal when a surface sends max + or - throw of 14Bit (IE 0x7fff or 0X000)?

If that's the case, the XTouch faders can never be commanded to physically move to +10db nor to totally infinity by Reaper.

That said, between these firmware limitations of the XTouch, in the current CSI code implementation, results in a slight mis-match between Reaper and the XTouch faders.

I am current normalizing this to cater for the slight mismatch, stay tuned :)

[higginsdragon]

I've attached the "FaderFix" that according to the original author adjusts the MIDI messages to send at a different rate, as far as I can tell.

MackieFaderFixer.zip

MackieFaderFixerSource.zip

[rwallingford]

A lot of code to look at there :)

From what I can tell, correct me if I'm wrong, seems more about preventing a flood of update messages, which Reaper all ready handles.

Did I miss something?

[FunkybotsEvilTwin]

There's some fader interpolation code in there to smooth out the fader response. The XTouch faders are notoriously chattery. Here's the interpolation portion of the code:

if (currentPitchBend.IsSet && elapsedMilliseconds < 500)
{
    uint32_t diff = abs(currentPitchBend.PitchBend - parsedMessage.DataBytesCombined);

    if (diff < _ignoreAbove)
    {
        uint32_t steps = elapsedMilliseconds / _faderInterpolationDelay;
        if (steps > 1 && diff > _toRound)
        {
            // For each step, create an interpolated message
            uint32_t increment = abs(parsedMessage.DataBytesCombined - currentPitchBend.PitchBend) / steps;
            bool negative = parsedMessage.DataBytesCombined < currentPitchBend.PitchBend;
            auto current = currentPitchBend.PitchBend;

            for (uint32_t i = 0; i < steps; i++)
            {
                auto interpolate = data;
                short finalValue = negative ? current - increment : current + increment;
                // Rounding, bounds checks, etc...
                interpolate[1] = finalValue & 0x00ff;
                interpolate[2] = finalValue >> 8;
                current = finalValue;

                _messages.push_back(ThreadMessage{
                    interpolate,
                    i * _faderInterpolationDelay,
                    end
                });
            }
        }

        _messages.push_back(ThreadMessage{
            data,
            steps * _faderInterpolationDelay,
            end
        });
    }
    ...
}

This section adds a little latency and pumps in the interpolated messages.

for (int i = 0; i < size; i++)
{
    auto& message = localMessages[i];
    std::chrono::duration<double> seconds = now - message.Sent;
    uint32_t elapsedMilliseconds = static_cast<uint32_t>(seconds.count() * 1000.0);

    if (elapsedMilliseconds >= message.StartIn)
    {
        _out->sendMessage(&message.Data);
        toRemove.push_back(i);
    }
}

Instead of a sudden jump between each message, the fader movement is spread out over several intermediate steps, supposedly making the response feel much smoother; just at the cost of some very small latency.