MCU volume fader data inconsistent - midi problem?

airon · 10-14-2019, 07:00 AM

After seeing this post on the CSI thread I began to do my own tests. User tdc was working on MacOS systems, but it could have been happening on a Windows system all the same.

Windows10 Pro, Reaper 5.983 x64, Presonus Faderport 16 using two MCU control surface entries.

The data received from MCU units are pitchbend midi messages. This is what they looked like for tdc (quoted from his post):

My data looks bad too. Here's the session, with mouse-driven fadermovement and then MCU driven fadermovement.

https://stash.reaper.fm/37319/MCU%20...automation.rpp

The fastest fader movements are revealing.

Mouse-movement-driven fader input

And here's the shit I get from MCU-driven fader input. It looks eerily similar to what tdc is getting in his screenshot.

When you look at the slower movements in the session, you see a stair pattern. Little jumps of up to 0.6 dB. This can't be right. What could be happening ?

Unfortunately I can't test this in Protools, because the HUI mode simply doesn't work on my unit.

Perhaps a Protools user can contribute a shot of the recorded (unsmoothed and unthinned) volume automation data ??

Conclusions ?
I've used midi/hui controllers for the last 12 years. I've never seen this kind of data in Protools before, ever. Yeah, I let it smooth (it has five levels of smoothing and thinning). I'm not even sure when I saw this in Reaper, because I rarely look at volume envelopes.

It may very well be that Protools smooths this data out, and Reaper just sits there and takes it. I think you're not finished with this yet gentlemen.

airon · 10-14-2019, 07:12 AM

I've been looking at the incoming data in MidiOx that comes from my Presonus Faderport 16 and it looks fine. No sudden jumps, but when flying in thick and fast like in the last screenshot in the previous post, some interpolation may be necessary.

That stair pattern looks like it's a very uneven capture of data from the controller. He's one second of this data during a slower fadermove. The jumps are 0.4-0.6 dB. You can see the data in the session I posted above.

Something has to be done about this. Whether that's better capture, clever interpretation with more granular thinning/smoothing controls or whatever else. This is pretty ugly, because the mouse-driven fader movements get recorded just fine.