I think you’re wrong. MIDI CC events are sent to a VST plugin as MIDI CC events. Cubase does not handle CC events any differently depending on what is connected at the output routing of a MIDI Track or Instrument Track.
One way we can conclude this is by using a VST plugin that has an internal MIDI Learn function. Enable the learn function and send CC events from a MIDI Part. That would not work if the data was translated to VST parameter before reaching the plugin.
In the Key Editor ramps look smooth and high res but… Your eyes can deceive you, don’t trust them.
I don’t think that is right… VST3 does not support MIDI per se, only Events or Parameters. Every MIDI message has to be converted by the hosts to one of those types before sent to the plugin. MIDI CC are converted to parameters and thus for the plugin the are same type as automation parameters.
That was actually one of the “features” of VST3 that annoyed many plugin developers and made adoption of the format so slow as it was a drastic change from VST2.
I didn’t know that. I stand corrected and thank you for bringing that to my attention.
This makes testing Ramp mode for use specifically with VST a lot harder. When the output of a track is a MIDI port, it’s easy to verify that data reduction is happening but now I can’t say I’m sure it applies to CC control of a VST.
I revisited this topic of Step vs Ramp vs VST parameter again.
I created 3 Instrument tracks and chose a the Arturia Mini v3 as my test subject. (I deliberately picked a non-Steinberg instrument.) I disabled all the VCOs and only used the resonant filter.
That is quite interesting (or weird). If the host maps MIDI CC to VST3 parameters and send those to the plugin as parameter changes (which VST3 requires), I would assume that the results are somewhat similar.
The first screenshot definitely is expected, the host sends all the parameters required to reconstruct the automation curve to the plugin and the plugin automates the filter in a way that produces smooth values. Like described in the VST3 docs:
The CC results look to me like Cubase does not send the necessary point at the end of the block, so the plugin has no “target” value from the last transmitted value to the end of the block and just stays on that last value (the “implicit point” in the picture).
It is a little hard to see with the step mode, but it looks to me like the steps are somewhat irregular, which would fit. Cubase transmits each value change to the plugin, which due to the drawing and screen resolution might be a tad irregular.
With the ramp example Cubase just seems to take the current value at the start of each block. I would expect a bit that the steps get wider the higher the block size, have you tested that?
Would be interesting to see if this looks different with a Cubase VST.
I meant processing block, which should be the same as the buffer size (but who knows)
Hm, looks slightly irregular, I think that means that I can throw my buffer size/processing block theory in the bin…
No idea. I don’t think it is data reduction", as a ramp imho is basically a vector graphic and not a collection of discrete values. But I think only someone from Steinberg can explain why it is like that. It’s definitely not good…
Visually, yes. But that’s not what the track outputs. Try creating a Ramp curve, export it as a MIDI file and reimport that same MIDI file. The Ramp has now been converted to Step mode.
Here is what that looks like.
yes, that explains it… in the context of a MIDI export, the quantization make sense and is necessary, but it seems like Cubase does the same before sending the values to a plugin, which when the documentation for VST3 is correct and CC should be converted to parameter values like automation doesn’t make sense… or I simply don’t understand the process correctly.
True, but why is it so coarse? The sampling is noticeably poor.
Also, just for completeness, the output of a MIDI CC Ramp on a MIDI Track, regardless of what that track outputs to, suffer from the same issue.
When all of these observations are summed up, it does appear as if the core issue lies with the Ramp mode is outputting at a much lower resolution than it should.
If I understand the VST spec you presented correctly, a series of discrete CC events should get interpolated and result in a smooth transition of the targeted parameter. So that appears to be a separate issue.
VST automation - time resolution is every few samples (I don’t know exactly how many samples), data resolution is 32bit float
Midi Step - time resolution is some more samples per event compared to 1), it also depends on the project’s tempo and sample rate, data resolution is 7bit
Midi Ramp - time resolution is quantized to an internally fixed, coarse value, data resolution is 7bit
For 2) and 3) Cubase uses the midi limitations first before converting anything to VST3.
I find this part unexpected. There is no indication that Ramp should produce a lower resolution result compared to Step. Visually, you’re led to believe the opposite.
This doesn’t surprise me. It was only when challenged by @Louis_R and @fese that I performed the above tests and shared the results.
I have skimmed through the VST3 documentation and found it a bit ambiguous. The part fese shared, showing host transmitted curve points per processing block, is from the section Parameters and Automation > Automation Playback and does not mention MIDI at all. But on the other hand, the section Parameter MIDI Mapping explains that Control Change events are translated to VST parameters by the host before reaching the plugin.
So any functionality that is to be controlled by MIDI controllers must be exported as regular parameter. The host will transform incoming MIDI controller data using this interface and transmit them as regular parameter change. This allows the host to automate them in the same way as other parameters.
So what gives? Why is MIDI CC entered as Ramp in Cubase handled with such a low sample frequency?
