Understanding CC Data VS Automation data

[dibraccio]

Hi

I am trying to get a better understanding of the difference between CC Data and Automation data.

My confusion stems from the fact that certain basic parameters of midi tracks, like basic Volume, Pan but also Continuous Controllers, can be controlled by either or both of the following:

• CC Data in a Controller lane in the Key Editor
  and / or
• Automation data in an AutomationLane in track view,

My experiments yielded some confusing results.

If I Write enable a midi track and record CC11 using a midi control surface, the CC 11 data gets recorded into a Key Editor, Controller lane.
The CC data does not get recorded into the Track Automation lane, but if I open the drop down to select an Automation type for an Automation lane , CC11 appears as one of the choices.
If I select CC11 from the Drop Down for the Automation lane, there is no data in the track event view, just a straight line.
So it seems like CC data cannot be recorded into the Track Automation lanes in real-time by enabling Write automation for the track. But Write enabling the track makes the CC11 appear as an Automation choice in the Drop Down.
I noticed that I can manually draw in automation using the Draw or Lines tools.

What I am left with after that is 2 completely independent sets of CC data , one in a Controller lane in the Key Editor, the other one in an Automation lane in Track view. Both sets of CC11 data affect the track simultaneously and independently.

When I Write enable a track and use a Midi Control Surface to write CC7 data,
the CC7 gets recorded in the Key editor Only. Not the Automation lane.

Visa versa, if I Write enable a track, and record Volume by using the Volume slider in the Inspector, the volume information gets recorded in the Automation lane but not in the Key Editor Controller lane.

I’m finding the overlapping of these features a bit tricky to understand.

One question I have is, if I manually write data in the CC11 Automation lane, is that CC midi data.

Thanks for any insight into this topic.

[Martin.Jirsak]

Hi,

There is settings to define, if you want to write (as an automation) or record (as a MIDI data) incoming MIDI CCs. You can set this up individually per MIDI CC. By default all MIDI CCs are recorded as MIDI data.

There is also settings, what should Cubase do in case of conflict (MIDI data and automation of the same MIDI CC at the same time). You can use one of them only, or you can merge them.

Regarding the presence of the MIDI CC11 in the automation tracks… There are all automatable parameters, not the parameters, which have been used already. Therefore you can see all MIDI CCs.

If you are talking about the MIDI CC7 vs the fader movement, you are probably working with an Instrument Track. The fader is in fact the Audio Return Channel of the given Instrument (it’s not the fader of the MIDI input), therefore it’s handled as an automation (same as the Audio track’s fader, for example).

[dibraccio]

@Martin.Jirsak

If you are talking about the MIDI CC7 vs the fader movement, you are probably working with an Instrument Track. The fader is in fact the Audio Return Channel of the given Instrument (it’s not the fader of the MIDI input), therefore it’s handled as an automation (same as the Audio track’s fader, for example).

Thank You

[Googly_Smythe]

This is not a pro description, but it may help…

Continuous Controllers were invented/designed (in the mid 70s, I think) to enable synthesisers and sequencers to work together, as part of the Musical Instrument Digital Interface protocol, an attempt to unify all the different synth communication methods around at that time.

Automation, on the other hand, was invented/designed for mixing consoles in a studio environment (SSL in the late 70s?). This enabled mix engineers to record fader movements, EQ settings, etc, and recall them at future sessions.

So use CCs to control your synths and automation for your faders etc, even though you can use both or either for similar jobs.

There are no rules, just inspiration!

[raino]

@dibraccio

What I am left with after that is 2 completely independent sets of CC data , one in a Controller lane in the Key Editor, the other one in an Automation lane in Track view. Both sets of CC11 data affect the track simultaneously and independently.

Yeah, it can be confusing. In your example you only have cc Data in the Key Editor. The Automation for controlling the cc isn’t really “cc Data” it is normal Automation Data. In Cubase Automation can be used to control almost anything, which means it can also control a cc Controller.

Normally if you are recording a keyboard performance including twisting knobs to play with filters (or whatever) via cc messages you would record that as MIDI data and leave it at that.

But if you want to create more precise sweeps after the fact, then using Automation might be a better choice. That’s because MIDI Data always immediately changes to the new value. So to create a ramp or curve you need to have multiple data points along the entire curve.

Automation data is much more flexible. In the example below it only took 3 data points to create a fairly complex shape. This Automation is not so much like MIDI cc Data that is being routed to the VSTi and more like using your mouse to adjust the knob in the VSTi which is set to be controlled by the cc Data.

[dibraccio]

Thank you for your insights.

Regards

[Johnny_Monteo]

This is really a good question and it can be answered in several ways. As far as I can tell all the replies above are correct. I will try to add a slightly different perspective.

In Cubase MIDI is being used because it allows different “musical instruments” to communicate with each other. Your Cubase is such a musical instrument. You might have a midi keyboard, that’s another. Hardware synthesizers would be as well.
However, VST3 plugins are not. They communicate only with their host (Cubase). And they don’t use MIDI for that but the VST engine.
For you, the user, however, it would be quite tedious to have two different systems when entering notes. Imagine one Key Editor for MIDI and another Key Editor for VST. So, Cubase tries on many levels to combine these two systems as non-visible to the user as possible. Most people think they are working with MIDI in Cubase when often they are actually working with VST.
The one area, where the two communication systems live side by side is MIDI CC vs. VST automation. You can use both basically at the same time as both have their distinct advantages and disadvantages. Unfortunately that can be confusing to the user.

[dibraccio]

Interesting. Thank you

[vitaliistep]

I was at the same confusing situation several days ago.
Just to add to the comments above you can combine both approaches and turn MIDI parts for the controller data that’s not available in CC to a kind of automation lanes like this: Automation lanes data is not visible on the tracker - #11 by vitaliistep

[Johnny_Monteo]

Basically MIDI is just used to be able to communicate with any outboard gear. Internally MIDI would not be used at all. Picture somebody not having a midi keyboard or any sort of remote controller. This person would just drag in samples and loops into the project and use the mouse to draw in any midi notes required. None of that requires actual MIDI messages and for this use-case Cubase could be made without any MIDI support whatsoever.

At some point Cubase converts MIDI data into VST data. VST is not just a plugin standard, it is a whole concept running within Cubase.
If data needs to be sent to the ‘outside’ than VST data gets converted back into MIDI data.

If you turn MIDI CC into automation you do exactly this conversion manually.

There is one thing that I don’t know: Exactly at which point the conversion from MIDI to VST takes place. It could be that all things you see in the Key Editor is actually stored as MIDI data in the memory of your computer but it could also be that this is all indeed already VST data and Cubase just makes it look like MIDI.

[raino]

@Johnny_Monteo

It could be that all things you see in the Key Editor is actually stored as MIDI data in the memory of your computer but it could also be that this is all indeed already VST data and Cubase just makes it look like MIDI.

I’d bet that it is the former, since the VSTi needs to be able to listen for MIDI coming in live. Also if you drag and drop a MIDI Part onto your Desktop the resulting file is only MIDI Data.

[emotive]

These days, there is no point in using legacy MIDI, for controller data since it is not uniform in how it can be edited, i.e., there is no Bezier methods and it’s massively cumbersome to edit.

The future is via SB proprietary automation, which I might add; needs major work but at least you will be ready for the future when the dev’s are able to make this data available as track data, i.e., from within tracks themselves but from all perspectives, it would appear that this will become a reality, as with C/N13, we can now edit Global Track data, in addition to solo/mute for multiple, selected (MIDI) tracks.

[Johnny_Monteo]

@raino

I’d bet that it is the former, since the VSTi needs to be able to listen for MIDI coming in live.

That is true for VST2.4. That is also what Steinberg wants to get rid of in the future and I assume it is the main reason why. VST3 instruments don’t listen to MIDI, except when they are programmed to access a MIDI input directly without Cubase interfering (working around VST3 for direct MIDI access).

@raino

Also if you drag and drop a MIDI Part onto your Desktop the resulting file is only MIDI Data.

There is also a conversion routine for VST to MIDI.

[ikos]

@Johnny_Monteo

That is also what Steinberg wants to get rid of in the future

What do you mean by this? How can they get rid of MIDI when literally everything else is MIDI-based?

[Johnny_Monteo]

Steinberg wants to get rid of VST2.x support, not MIDI support.

Small remark to MIDI:
MIDI is widely spread and its basically the only exchange of data in the world of music making that is supported by everyone and their mother.
But MIDI is also a giant bottleneck full of limitations, that, quite frankly, hold us back. The only reason that we are still using it is that the industry could not agree on anything better for 40 years. We’ll see how MIDI 2.0 does once it gets widespread support.

[ikos]

@Johnny_Monteo

MIDI is widely spread and its basically the only exchange of data in the world of music making that is supported by everyone and their mother.
But MIDI is also a giant bottleneck full of limitations, that, quite frankly, hold us back. The only reason that we are still using it is that the industry could not agree on anything better for 40 years. We’ll see how MIDI 2.0 does once it gets widespread support.

I agree, but it’s not going anywhere.

VST3 abstraction is better in theory, but it’s not fully adopted. For example, no major VST3 host, other than Cubase, supports note expression.

And even Steinberg didn’t fully abstract MIDI away. Dorico can’t yet automate VST3 parameters, only CC. Cubase still doesn’t have native modulators such as LFOs, envelopes s and scripting for VST3 parameters, we have to do those kinds of things via MIDI. They are not leading by example.

[Johnny_Monteo]

Thank you for your reply. I am not arguing against any of that.
I stated that Steinberg will drop support for VST2.x at some point in the future.
And I stated that I would like to see MIDI 1.0 replaced sooner rather than later. I am a fan of it for what it has done in the past. I am not a fan of it at the present as it still lingers around, being outdated.

[Googly_Smythe]

@Johnny_Monteo

outdated.

MIDI/VST2:

[Johnny_Monteo]

Funny but not funny. Somehow I feel that when I talk about MIDI somebody hears VST. And when I talk about VST somebody hears MIDI. A bit weird.

Edit: Post, that this was related to, has been altered.

[Googly_Smythe]

Since both (MIDI/VST2) are outdated any phrasing I used to combine them seemed odd, so I went with VST. Since the topic is more MIDI, I should have gone with that. Hey ho.