If my MIDI device sends: CC 07 (Main Volume) – data=1
Then Cubase receives: CC 07 (Main Volume) – data=0
I’ve realised that Cubase treats any received “data=0” as “data=off” and this is why there’s an offset for the rest of the values.
But why? Why does there need to be an “off”? Isn’t just setting a controller to 0 sufficient? Even for panning, an acceptable default is just C.
Not only why, but how can I get rid of this? It tends to occur at random times but I think I’m starting to figure this out…
From “off” to 127, there’s 129 values. From 0 to 127, there’s 128 values. Rather than just shifting the regular values up by 1, it’s as if Cubase tries to make the regular 128 value range “stretch into” it’s 129 value range by making the regular range’s values represent 128/127 instead of 1/1. Depending on how the software is rounding the values, this could easily result in offsetting by -1 and 1. Not to mention floating-point innaccuracies… I haven’t tested this yet, but I’m guessing that 63 will round down and 64 will round up.
As a side note… is there really a “center” value in MIDI? 64 isn’t in the dead center of a 0-127 range. It’s slightly to the right… or is this why Cubase has an “off” value. To compensate for that?
Of course, there’s always the possibility that it’s my MIDI device.
“Off” appears in the MixConsole below my MIDI track faders when they’re turned fully down. It also appears next to the panning bar when panned fully to the left.
I always expected that the MIDI faders and the panning bars would correspond to the data being received. But they’re often offset by -1. Because I record volume and panning automation tracks based on these faders and bars, I’m always seeing the offset.
I key in MIDI CC messages into an external device and literally record them into a Cubase MIDI track. For volume and panning, I enable “write automation” and use automation tracks. For the rest of the CC messages, I record them just like I’d record notes, and they show up in their own controller lane within the track.
Sometimes even the controller lane data is offset. For example, I tried to turn my modulation wheel all the way down using pre-programmed automation and so keyed in 0 (into the external device) and recorded it. Only to find out that I’d recorded “off” and not 0 like I intended. So I then had to manually change the value within Cubase. In this scenario, it’s not a huge hassle, but sometimes I record tonnes of CC for things like fade-ins, fade-outs, pitch-bends, cutoff sweeps, etc…
So there’s probably no way around it if it’s built into the software?
Well actually, come to think of it, there’s always the input transformer. I was hoping there would be a preference setting. But I guess not.
There must be a purpose to “off”. Otherwise it would just be a synonym for 0. That would have been easier to implement so surely there’s a reason why Cubase goes out of it’s way to compensate for this value.
IIRC Off means no value is transmitted/sent. And if set to a value then the value is only transmitted/sent when you start up the project, although new values are transmitted when you move the fader.
Note that if you don’t have any automation nodes then the fader value is not chased anymore like it used to be - this behaviour is worth bearing in mind when you change the volume of an instrument via it’s knob and then wonder why Cubase doesn’t reset it back again.
Actually, I haven’t tested this in a long while so I’m simply assuming its not been changed recently
I can understand that. But I wonder why they didn’t implement “off” as a Cubase specific value.
Clearly this is something like the current logic behind it:
“if sent data = x, and received data = y, then y = floor(x / 127 + x - 1)”
This would explain the missing 126 value on-screen. Behind the scenes though, the floating point results could be used to create a more accurate linear representation of the physical controller movements. Alternatively, because this is a computer program, some sort of integer trunc() function could be used instead.
More likely though, the implementation of the logic is just:
“if sent data = x, and received data = y, then y = x - 1, except if x = 127, then y = x”
It would give the same result and I imagine would be more efficient though it looks cumbersome.
I don’t understand the point of implementing “off” as an addition to MIDI. Unless of course, it’s actually part of the MIDI standard and I just didn’t know… I’m probably just thinking way too hard but I find it interesting.
In binary format, “off” would be most intuitively implemented in a byte as 10000000 (otherwise known as -1 or 128) because it doesn’t directly interfere with incoming MIDI. I’m guessing MIDI standard data in this block only ranges from 00000000 (zero) to 01111111 (127) and Cubase decides to use the spare bit to store “off”.
Now this is great, but why on earth does Cubase need to modify incoming data to fit this model? Cubase can still retain it’s “off” functionality but respond intuitively to incoming data. 0 should be 0. Even if Steinberg develops their own MIDI controller with “off” functionality built-in, other products should function as expected right? If someone has a MIDI controller without “off” functionality but they wish to use “off”, this functionality should only be able to be switched manually within the DAW itself by nudging a slider down 1, and therefore bringing back 126 and removing offsets. If they really want to be able to use “off” without touching the DAW, then they should get a product specifically for Cubase. After all, “off” is specific to Cubase. Am I right?
Those are pretty much my final thoughts… And yes I know this is petty.
