While there are many ways to use Event Volume and accomplish any given scenario, the whole experience could be more pleasing and care-free.
Suggestion 1
Instead of using a macro to split a range and apply a set DOP gain at once (which is fine), it would be interesting if there was an option for the range tool to automatically create its own Event Volume Control for any qualifying tracks. Then for a mouse based workflow it would be a matter of “drag to define range/drag up or down to adjust volume”. Or “drag and press key” if a set amount of gain has been assigned to a key command. The benefit of this approach is an overall cleaner look, and not having to bounce to get rid of all the splits in the end.
Suggestion 2
Event Volume Curve should default to 0, and said zero should be at the center of the event. If the current approach of design is desired instead, mimicking a fader’s 0, an additional “pre-gain” trim should also be represented somehow.
Which brings me to the next thought. Wouldn’t it be useful to have a way to translate the event gain envelope to automation if needed? Or vice versa? And wouldn’t it be nice if there was an option for automatic “smoothing” of data, if we wanted to, that could be applied to the resulting automation curve in a similar manner to project auto fades? Smoothing all those coarse blocks on ranges made by quick editing into curves, steeper or shallower.
Suggestion 3
Regardless of the above outlandish suggestions, it would really be helpful if data could be displayed in a tooltip when drawing an event volume envelope, or hovering over a node. Right now everything is approximate and done by ear (not a bad thing), but the moment the user desires a specific value they are forced to work around the situation. (Split Range, Set Event Volume to specific value, then eyeball drawing the evelope curve from the top of the event that equals that specific value)
I’m also curious to see if this will be taken in to consideration. Currently the way event volume is structured is quite basic and could do with an overhaul especially being able to see event node values and being able to use range tool to bring a selection up/or down
Event Gain in general needs to be modernized - bezier curves, gain increase instead of only decrease, use of range tool which I’m not sure how range would work, perhaps using a modifier but which I’m not sure because range tool already uses some modifiers.
And just let users decide in prefences the range of gain, and the placement of 0 whether it is at the top, or event center. ie, if someones wants 18db up or down with the 0db line at center, let them set that.
It’s sort of surprising it has been ignored… editing at the event level is such a commercial industry standard thing, but the workflow with it in Cubase is non commercial industry. It’s very archaic and cheap feeling like something you would encounter in one of those cheap $20 DAWs.
…
Not to mention, there’s no reason AI couldn’t handle this work and just auto-balance a clip and automatically draw a line for you based on RMS measurements and Fletcher-Munson, and then you could tweak the lines as needed.
So you’re saying something like Bezier curves might not be compatible with AFF? Where there’s a will there’s a way, they could program it so that when a user grabs onto a Bezier elbow and, drags, and release, it converts the bezier curve into AFF compatible points. Where there’'s a will, there’s a way.
I was also thinking, perhaps it would be good if there was a Event Volume Editing track mode, in this mode, the primary editing objective is grabbing Event Volume points, and thus, all tools become Event Volume focused including the object selection tool. So, if you shift+click+drag on an event, it doesn’t select the event, it instead selects any Event Volume nodes.
A case example would be, having just recorded three tracks of vocals. silence cropping, event moving, slicing, etc is already all done, now the user wants to dig into volume balancing… they can select all three tracks, enable Event Volume Editing mode, and freely move between all events across all three tracks tweaking away.
Perhaps in this mode, event grabbing/resizing could still be accomplished by creating the mini-event lane you see on MIDI tracks when in Editing In Place mode.
In fact… this could be the audio track version of ‘Edit in Place’, and the same key command could be used. tahdah
I voted, and I’m going to create a new FR and vote there as well
That’s true. But it’s an engineering problem which I have no doubts that some cunning can be employed from the programmers to solve it. We have ramps (and curves) for MIDI, where it’s obvious that there are discreet controller values, and not continuous f(x)=ax lines that accept any value. So, some method can be interjected between the feature’s UI and what it actually does behind the curtains, so that it conforms to established standards.
Yes, they should! But it’s a tough task for the mods, considering there’s at least one request with ideas for improving the event volume per Cubase version, and I’m not sure all are asking for the same things.
Yes, I was just thinking out loud about the presentation of the compilation of feature requests, so that it would cover most users’ preferences. Instead of having a barrage of shrapnel of ideas, have a focused, solid, cannonball of a request.
I had written a whole sheet juggling details, but it was so tiring to read that I just erased it all, and will offer a simpler proposal instead. What if we made a poll, with some points pertinent to the request, and then see if there’s a common direction that most of us agree on?
Good idea in theory, but as said previously: the Devs will implement their own take of a feature, if they think it is a good one. At least it has been like this in the past, so imho that is just a waste of time unfortunately.
It’s probably as you say, a waste of time, but I can’t help but think that one of the reasons that this particular issue is not being tackled all those years might be due to the diffuse presentation of the requests.
Because, on paper, the job is done with the already available tools. So it’s understandable that unless we exactly pinpoint what needs to be improved, steinberg will be understandbly reluctant to revisit an already complete feature. (Why fix it if it works kind of thing.)
