I came across a serious issue with automation in an earlier Cubase, but I’m asking here because I’m hoping to find out whether it’s still an issue in Cubase 9, and if so, what workarounds people use.
Whenever I draw a curve in an automation lane, some values are shown in the small box that pops up next to the pencil tool. Here’s an example showing what I’m talking about, where I’m drawing an automation curve for one of the parameters in the factory Spector VST synth. Note how both the position and the value of the parameter are updated next to the pencil as I’m drawing:
However, this information box does not seem to update when drawing an automation curve for any parameter in any of the non-Steinberg VST instruments I’ve tried. Here’s an example for a third-party instrument called C700. Note how the position is updated as I’m drawing but the value of the parameter is not:
What’s worse is that the points in the automation curve cannot be hand edited later to match exact values, because only relative values on a scale of 0.0 to 100.0 are shown in the info line and project browser for automation points in third-party VST instruments, at least as far as I can tell.
Is anyone else experiencing this? Is there anything I can do to work around it? What do you do when an automated parameter of a third-party VST instrument needs to be set to an exact value?
Third party VST3 plugins still seem to be pretty rare, but when I tried it with the only one I have (FabFilter Twin), the bug was not present. Also, I tried it with an old Steinberg VST2 plugin (a1) and the bug was present. I guess that pretty conclusively shows that it’s a problem with VST1 and VST2 plugins that was solved with VST3.
Can you confirm this with your setup? I’m especially interested if this particular bug is still a problem in Cubase 9, because it might be just the motivation I need to finally update. Also, if this is still a bug, do you have any ideas about what I can do when a VST2 plugin parameter needs to be set to an exact value via automation? How do people work around this?
Right, the parameters of Cubase mixer controls and the parameters of VST3 plugins work as expected. However, I’m wondering about the parameters of VST1/VST2 plugins.
Say I have a sample in a VST2 sampler, and I want to use automation to modulate the pitch in a sine wave pattern in a range between exactly -1 to +1 half steps. Apparently there is no way to actually edit the automation curve to achieve this without drawing in some points, playing it back to see what effect it has, adjusting the points again by a tiny amount to get a little bit closer to the desired value, playing it back again, adjusting again by a tiny amount, etc.
Call me crazy, but I would like to simply see what pitchbend value I am actually entering when I draw the automation curve, or at the very least, be able to edit automation points in the timeline to set them to an exact value. It appears that both those are impossible for VST1/VST2 plugins though. I feel like I’m missing something here, because I don’t see any other mention of this issue on the internet. Does nobody else have a need to enter exact automation values?
I don’t have any VST1 or 2. I use VST2.4 & VST3 and all of the automation points I use can be edited exactly in the info line. The only way I know (there may be others) is to scroll from automation point to point where I want to edit the value to be exact. Highlight the value and type it in (however, once highlighted you can use the up/down arrows but it is tough to get the value exact). It is a bit tedious but, it does work.
Yes, automation points for any VST 1.X, VST 2.X, and VST 3.X plugin can be edited in the info line. But what I’m saying is that apparently for any VST 1.X and VST 2.X plugin, only meaningless floating point numbers between 0.0 and 100.0 are shown in the info life, not the true parameter values. Furthermore, like the pictures in my original post show, the true parameter values for any VST 1.X and VST 2.X plugin are not updated next to the pencil tool while drawing automation curves in the automation lane.
All this means that there is apparently no way to set the parameter values for a VST 1.X or VST 2.X plugin to an exact, meaningful value via automation other than by trial and error, as follows: draw the point, start playback so that the effect of the automation can be observed in the plugin, go back to edit the automation point, start playback so that the effect of the automation can be observed in the plugin, etc.
If anyone knows of a better workaround, please chime in!
As far as I’ve been able to determine there is no work-around for this. I first noticed this kind of issue when I was attempting to automate the Chopper Plug-In and found that the values on the automation line were not reflecting the state of the actual automation. For example, the length was being changed from 1/2 to 1/32 notes and the two points on the automation line looked exactly the same. It’s a complex issue to describe and to identify, but, it does exist and there is, apparently, no exact workaround for it.
What I’ve found is that the correct values are performed, even if they are not displayed. However, setting exact automation point can be very tedious and tricky. In the VST3 plug-ins these issues were, apparently, addressed. In those, the values do change and corresponding controls on the plug-in’s GUI do move.
So, as far as I’ve been able to determine, the Automation does work but is lacking in display accuracy for some if not all of the VST2 and plug-ins. Here’s a link to my thread on the Chopper Automation. You’ve identified what I think is essentially the same issue in a different context. re: chopper automation: https://www.steinberg.net/forums/viewtopic.php?f=250&t=111349
Somehow I’ve learned to cope with this, but it’s certainly not an ideal situation. Perhaps other more experienced or expert users will be able to offer us some more help with this.
Thanks for your reply Stephen. I think maybe the problem manifested a little bit differently in your scenario because the Chopper automation parameter values were discrete subdivisions of the bar (1/4 notes, 1/32 notes, etc.) and not continuous as in my screenshots. But yes, it seems to be the same fundamental issue.
Besides a trial and error approach, the only other workaround I have thought of is one that appears to be similar to the one recommended in your thread, which is finding a formula that maps the true value of the parameter in the plugin to the generic 0.0-100.0 parameter values used in the info line. That enables you to assign exact values to automation points by selecting an automation point and entering the correct generic value in the info line.
Finally, it occurs to me that this issue is basically the same issue that people have always faced when controlling a plugin parameter via MIDI CC, because the values of the CC message are meaningless numbers when you work with them in one of the MIDI editors. So I guess people have always just dealt with this same issue in one way or another, even before digital audio existed. When automation was performed by physically moving the faders on a mix console by hand, there was (I assume) no way to get exact values and people didn’t complain. The fact that VST3 at last seems to have solved the problem is really just spoiling me I guess!
I always assumed (and I obviously could me wrong) that that reason for the discrepancies in automation parameter values was just because the VST 2.x SDK didn’t have an “established standard” for the host and plug-in to be able to display it. Of course Cubase can’t properly display a value if the plug-in doesn’t tell it what the “units of measurement” are for the parameter. There are literally an infinite number of possibilities for the range of values for a parameter and those can be continuous or discrete and they aren’t necessarily numbers either. For example, a choir voice instrument may have a “Vowel” parameter (a-e-i-o-u).
So, I wouldn’t necessarily say it is a bug or even an “issue” but perhaps a limitation of the VST2.x SDK.
I would almost certainly say that it is likely not a problem with Cubase but a problem with the plug-in and how it is written to communicate the parameter value ranges to the host. After all, Cubase can only display what the plug-in tells it.
Anyway, something to think about. The good thing is that with VST3, they seem to have found a way that works.
In the other thread I mentioned, someone offered a good suggestion; this formula: 100 \ 18 (stages) results in a value of 5.55 per stage. Not perfect but does, more or less, address the primary automation issue for beat-division automation changes. And it might be helpful with continuous controller changes, fader moves and so on.
@jaslan & OP
I never had the pleasure of working with Mix Automation until Cubase Pro. The more I learn to work with automation, the the better I like it. Even with its imperfections, be they related to how Cubase works or related to the automation limitations or oddities of whatever Plug-in or instrument is being worked with, Cubase’s automation system is workable and powerful. Certainly worth struggling with a bit in terms of the pay-off automation brings to any project.
I’d like to see an “in depth” video about all this from someone.
If it’s a control with a continuous, linear range, then Algebra 101 gives us:
m = (g2 - g1) / (t2 - t1)
t1 is a “true” control value and g1 is the corresponding “generic” automation value in the info line t2 is another “true” control value and g2 is the corresponding “generic” automation value in the info line
The slope m, either of the pair of points above, and a desired true control value can then be used to find the generic value that gives any desired target value:
g = m * (t - t1) + g1
t is the desired true control value g is the corresponding generic value that you can enter in the info line to achieve the desired true value
Excellent. I think I follow this, but I’m not sure how we’d implement this in practical terms inside of Cubase – some kind of local editor or macro chain perhaps? For the most part, I want the Automation to be recorded as drawn or performed more less in the background, and, for the most part, it does. The problems seem to manifest when we want to make fine adjustments and run into the problems you and I and others have identified.
Frankly, I wonder if anyone really understands automation on a very deep level? So many of the videos about automation and the documentation itself about it are very thin on depth. While they may detail what Automation does and its basic tools, they don’t tend to go into the fine details. The result is threads that unearth problems or issues as mentioned in this post and others. Anyway, I’m all for interrogating the automation functions more deeply, and I’ll try to work with your suggestions. For the most part I’m pleased with how Cubase’s automation works. Automation is an expected part of the modern DAWs, but it’s still a huge luxury to have.
Thanks for your thoughts about this. I’ll keep working with it.