Please, Steinberg, a real clip gain! - actually "event based volume envelope"

I hate to argue against my own case but if you put the events into an audio part first and then time stretch them you will get the desired result.

1 Like

Pre or post event volume?

But you may not want to do this, for all sorts of reasons, such as being able to readjust crossfades, or modify part of the content. There are always ways of doing this apart from clip gain (or gain-event…), but the simplest thing would be for it to exist and be effective.

Putting events into an audio part (containerizing) takes away none of the things that you mention.
It is true, however, that the method requires two extra clicks: containerizing the events and then disolving the container afterwards and, of course, it would be better if we did not have to perform these clicks.

1 Like

Plus one floor (the container). But you’re right about that. The thing I personally hate is the multiplication of crossfades, which are necessary because of these obligatory cuts. What’s more, it has to be said that crossfades require memory, a bit of dust each, but by adding so much, it can become a bit cumbersome. In any case, it’s not “natural”. It’s a “necessary” evil, as they say, because of the bypass. I’ve been discussing this for years (and I’ve gotten some very nasty criticism for it, including personal attacks) and nothing is changing my mind. No doubt one day Cubendo will arrive with this “novelty”. That said, with respect, Johnny, I got caught up in the game, but I’m going to stop talking about it. I’ve really said it all on the subject, here for two years and on the Cubase forum for years before that. Best regards.

No Mute, you are again talking about manual insertion of points.
These are auto created in S1 and PT, and S1 only recently added it, with PT it’s been there for a decade or more.
Just highlight the bit of audio you want to adjust the volume of, it couldn’t be easier, and when you go to move the level of that bit of audio up or down, you just have to have faith and know the level bar is there and you quickly get used to it, and then all 4 required nodes are auto created.
It is SO fast.
Yes, what you are talking about is still way better than Steinberg’s pencil, for sure, but it’s not a common DAW thing to auto create event gain points.

Johnny, no problem. I guess I’ve never heard them called any other way in near 30 years of DAW use, and I really didn’t know that Steinberg referred to clips as events, but that’s fine for this forum. I will have to get used to it, as this is the first time in my life I have been asked not to refer to something as clip gain. But I’ll manage :slight_smile:

that´s only a clunky workaround!
why should I render something into a new audio wav if I want to make adjustments later? what if I want to adjust these event envelopes later again.
not possible because it´s baked in…

why not both switchable?
Samplitude has AUX sends on audio events (!) and much more:

I really love this editor window called audio “object editor”!
because you can have Insert plugins and EQ and Pan on every event too…

Just for your information: he is not saying you should bake, but group the events. That is a 1 click thing and does not create a new file or anything.

Although I tend to agree with this, one has to be realistic and admit that Sequoia/Samplitude was built from Day One to work this way, whereas implementing a similar approach into Cubendo’s existing engine might be a lot harder than it seems from the outside.

1 Like

I seems to me you don’t know what an audio part is. Can you look it up in the manual, please?

I don´t want extra grouping.
This is an absolute hindrance to freely designing sensible volume curves.
In my > example there is only the possibility of render a new audio wav to do this. Only then it´s stretchable but all volume envelopes are lost and that’s what I was referring to.
grouping/parts etc. are not up for debate at all.

1 Like


and how do you draw a volume envelope on a part?

I want to have access to volume envelopes directly on an event, not somehow via parts, grouping or other half-baked workflow nonsense.
Like in other modern competitors PT, S1, Reaper etc.

You are getting way to upset to argue rationaly.
I am one of the loudest advocats for event based volume envelopes. Maybe you haven’t read the entire topic and therefore haven’t noticed that.

However, you gave an example how an event, that you cut into several ones in order to have several gain settings, cannot be time stretched. And that is just a bad example because it can be done - by containerizing the events into a part, timestretch and then dissolve that part afterwards.

So, your example was just not a good one. But in the end of the day we both want the same.


Well that’s not really a level envelope for AUX sends. To me adding envelopes with pre/post attributes will make for a bit of a mess potentially. I’m ok with having it as an option as long as it doesn’t get in the way of other workflows. Having said that though I think there are more important things to focus on.

As for that object editor and inserts on events that just seems like object based processing. It’s been requested multiple times on this forum and it’s really a different thing than what this thread is about.

1 Like

Certainly it is because english is not my native language. I´m sorry.
I gave this example because without grouping or parts it´s not possible to simply apply and edit a complete continuous (!) envelope on an audio event. Maybe it’s more understandable now?

absolutely. Thank you.

1 Like

I don’t think that´s too complicated to integrate. Not just because other daws have this great feature.
“AUX sends on events” are nothing other than normal routing pathes that we’ve had available in the audio mix console for decades. It´s real-time processing. This also applies to real-time insert effects on events.
All this is realtime processing, what Cubase Nuendo already has.
(The opposite is DOP (F7) with it´s non-realtime effect processing on events)

that´s right. Let’s go back to the opening post.