This one’s pretty simple and straightforward. I’d like to be able to change tempos in a smooth, non-linear way with bezier curves, like we now have on automation tracks. (btw I know a lot of us also want the bezier curves to apply to the midi controllers as well)
To me this is a bad idea, although I’ll be the first to say that B-curves in the key-editor are essential and much desired.
If you have 16th notes and change tempo every 16th note (a pretty extreme condition), then any tempo event between those 16th notes is causing unnecessary computational thrashing. Such would not only require Cubase to work harder (or make your CPU work harder on its behalf), it could make certain types of tempo-synced plug-ins work vastly harder. With B-curves, you might have tempo change events spaced more closely that 64th notes. Even with our extremely fast modern DAWs, this could be a problem. I’d much prefer SB spend their time getting us B-curves in the key editor anyway.
A bezier curve would be no different than the current straight line in this respect. (fyi, using the straight line changes the tempo far more frequently than every 16th note without causing any computational thrashing.)
Clarifying Glenn0 is referring to Ramp as compared to Jump type of automation - 'cause they both are displayed as straight lines - although one only uses 90° angles
And the point is well taken that the resources needed to do a bezier rather than a ramp is negligible if it even exists.
I would argue that there is no computational thrashing. To begin with, if you have two notes some time interval apart. The listener has no way of knowing that there is a single tempo even controlling their time separation or a hundred tempo events between them. So, the intervening tempo events are unnecessary data.
Now, I can tell you with some authority that tempo events can be a bit of a headache when writing code that processes them in VST-type plug-ins. They don’t fit well in the structures of data handed to the VST. If the tempo events are particularly dense, this could actually cause some inaccuracies in the playback because the relationship of the tempo events and the samples handed to the VST are not integrated. If you have a continuous stream of tempo events that are occurring at intervals of milliseconds, that’s potentially bad news.
I’m the author of the ultimate tempo synced virtual instrument, Stylus RMX, and I agree and can confirm that a bezier curve for tempo would not cause a problem .
Bezier curves should be standard.
What about bezier curves on fade audio files
They sort of do have something like Bezier curves for audio fades/crossfades.
I think maybe some other person/people said this, but you’re already changing tempo constantly when you create two tempo points and select ramp. The only difference would be that one would travel linearly and the other would move between linear and somewhat parabolic. Since we’re already able to warp the tempo constantly, and we’re even able to draw in lots of points by hand, I don’t see how it would be impossible to compute bezier curves.
Even if it WAS intensive, you could just bottleneck the actual sample rate of the bezier curve.
I’m not sure what you mean by “bottleneck”, but I’m guessing that you mean placing tempo events on the curve but limiting them to a reasonable density (e.g. one for every eighth note). If that’s the case, yes, this would be a sensible way to accomplish what you want without choking the machinery with unnecessary data.
Bottleneck must be more of a colloquial term. Instead of bottleneck, maybe I should say quantize. And yes, that’s what I mean. Limiting the number of data in between points to be finite. Similar to what a bitcrusher/sample reducer does. Unless I’m mistaken, this is how the curves work already. While the math may be infinitely precise, the end result has to give a finite number of samples, which I would imagine adheres to sample rate.
I mean, technically no digital music is smooth at all. There’s a very finite number of points, but the fidelity is usually so high that we can’t hear it. So I don’t think it’s a matter of do we quantize or not quantize… but rather it’s a matter of what level of quantization we apply.
I think this would be a nice option to have - when you do want a non-linear transition it would be more slick than approximation by multiple stages of linear steps.
As an aside, having just spent a happy hour tracking down some zipper noise which turned out to be linked to a linear tempo change upsetting a VSTi (Spectre) with a tempo locked delay in the patch, sometimes even linear changes can cause unforeseen problems. I don’t expect that a bezier would be any worse with one proviso that with extreme curves it would presumably make make for a lot of large tempo changes in a short period of time - which may make for a more prominent zipper noise effect in susceptible plugins, perhaps…
As already mentioned in a previous post in this thread, the tempo track updates at a very high rate when using ramp transitions - presumably beziers would be the much same in that respect.
Well, it’s a fact of life that some plug-ins do not take well to tempo changes period, even if they arrive only occasionally. For those, it’s best to set them to non-tempo-sync and dial in a suitable “average” manual tempo setting.
Yeah, especially tempo based delays. Heck they usually do something weird while you are manually adjusting the delay time.
I think the best way to manage this is to do as much work as possible using a fixed tempo. Next render the Track to Audio. Then you can mess with the tempo. Not always possible to do this, but if it is…
I know implementing time automation is a headache so i -----1, don’t even want the developers wasted time on this