Grab and Bend Automation and Envelope Shape

Instead of being limited to jump, linear, fast and slow shapes for both envelopes fades and between two automation points. Why not have a little "graphic indicator" in the middle of any given envelope and between any two automations points that you could hover the smart tool over or by pressing a command key to indicate and "grab"... then while holding, you could move this "graphic indicator" around to change the shape to the desired curve. The shape would always be "curved" and smooth, but depending on where you placed the "graphic indicator/node" the shape could go from linear to exponential (moving on the vertical plane) to how quickly and when/where most of the change would take place (on the horizontal plane).
 
At it's extreme, you could have shapes that were almost identical to jumping between two points, but now they would have a very quick, but smooth transition. Potentially useful for when jumping creates automation noise on a particular VST/VSTi setting... you could change the speed of the change until the offensive noise was no longer being made.
 
Not only would we have much more options for envelope and automation shapes, but we could also even create shapes between two points with the same vertical value... ie what was once a straight line on the horizontal plane could now become a "smiley face" or a "frown". Great for when you need a quick but smooth volume or other automation boost and much quicker than creating another two (four in total) automation nodes to achieve a smooth increase/decrease.
 
What would work between two automation points, would also be the same for clip fade editing. The same process of hovering the smart tool or pressing a key command would show the "graphic indicator" for envelope shape editing. The user could then move the clip fade shape around for the desired curve... no longer limited to only three different shapes.
 
Think it over and contribute any other ideas for creating more fluid custom envelope shapes with ease. I'm sure we could come up with some other great ideas for this...
 
Thanks,
Benjamin

I was just thinking about adding the same request. +1

I voted because Steve voted.

No being a huge user of automation or being familiar with what other DAWs have to offer, I would ask that you take the following with a grain of salt, but here are my initial thoughts on this:
 
First, in order for SONAR to process an automation curve between nodes (and to display that curve in the first place) it needs a mathematical function to follow. Generating that function from a user's dragging a single randomly chosen point on a line between to nodes to some randomly chosen destination and keeping it simple enough to be efficiently evaluated in real time (both for re-drawing as you drag and during subsequent playback) seems like a pretty big ask.
 
Second, I suspect that people overestimate the audibility of different transitional shapes between nodes, and that there isn't a lot of value in having access to different curves between Fast, Linear and Slow. But I suppose that might depend on what's being automated.
 
Regarding the specific goal of having "shapes that were almost identical to jumping between two points, but now they would have a very quick, but smooth transition", this is already possible using the existing Fast and Slow curves - or a combination of the two - with nodes very close together in time. At best, I could see adding 'S' and reverse 'S' curves to the repertoire to make it unnecessary to combine fast and slow curves to get smooth transitions between levels at both ends.
 
But I'm open to hearing examples created using multi-node curves that differ materially from what can be done with just two or three of the existing segment types. I'd need to hear that before giving a thumbs up. Otherwise, this kind of sounds like a solution looking for a problem that doesn't exist.

brundlefly
No being a huge user of automation or being familiar with what other DAWs have to offer, I would ask that you take the following with a grain of salt, but here are my initial thoughts on this:
 
First, in order for SONAR to process an automation curve between nodes (and to display that curve in the first place) it needs a mathematical function to follow. Generating that function from a user's dragging a single randomly chosen point on a line between to nodes to some randomly chosen destination and keeping it simple enough to be efficiently evaluated in real time (both for re-drawing as you drag and during subsequent playback) seems like a pretty big ask.
 
Second, I suspect that people overestimate the audibility of different transitional shapes between nodes, and that there isn't a lot of value in having access to different curves between Fast, Linear and Slow. But I suppose that might depend on what's being automated.
 
Regarding the specific goal of having "shapes that were almost identical to jumping between two points, but now they would have a very quick, but smooth transition", this is already possible using the existing Fast and Slow curves - or a combination of the two - with nodes very close together in time. At best, I could see adding 'S' and reverse 'S' curves to the repertoire to make it unnecessary to combine fast and slow curves to get smooth transitions between levels at both ends.
 
But I'm open to hearing examples created using multi-node curves that differ materially from what can be done with just two or three of the existing segment types. I'd need to hear that before giving a thumbs up. Otherwise, this kind of sounds like a solution looking for a problem that doesn't exist.

Hey Brundlefly, thanks for your thoughts!
I love the idea of the S shape... I think that would be something that would ideally be a right clickable feature, similar to the fast and slow shapes, no? Another time saver worth having for us that use lots of automation.
 
As far as my idea goes...
 
I honestly doubt that the calculation would take much more effort than it would to simply change from linear to fast or slow. I'm not sure why you would make that speculation or assume that it would be a deep processing burden. We can draw LFO automation in seconds, without the CPU flinching... we can calculate transients nodes, instantly... And you think we couldn't change the shape of automation without a CPU hit? A Do you have any evidence or knowledge to support this? I'm honestly curious why you've suggested this, as I have no background in DSP processing/calculation.
 
Why would this feature be useful. Simple, it would help save time for people doing lots of automation.
 
In terms of clip envelopes, the current shapes aren't enough... say if your fade out simply doesn't sound right. You can't change the shape of the fade envelope... You'd have to create a clip gain envelope and enter in multiple points, right clicking to change the shape between certain points. What if you have to do a complex fade out between 10 different tracks. Possibly hundreds of mice clicks later you could get the desired results... you could grab the envelope of ten tracks and move to the desire position.
 
I use tons of automation and it is very time consuming to get the desired results on certain sources (I often spend hours on a song for automation alone). A lot of times I will put down a couple of points between say a verse and a chorus... simple example would be a volume change from one section the next. Now lets say I need that transition to be smoother. Instead of having to put down another node and then right click to change the shape I would only have to grab between the two already existing nodes and move to the desired shape. That may not sound like a huge time saver to someone that doesn't use automation, but if you're doing this 30-40 times in a song, then it starts making a significant difference in workflow. At least it would for me...
 
Another example of where the existing shapes aren't enough is when automating a lead vocal track. Say I've got a very complicated vocal comp where you're jumping between 10 different takes and one particular phrase sounds great but one word sounds strange... I'll comp in the word from a different take. In the take lanes I may need to really fine tune the volume and transition between this word with the rest of the phrase. Sometimes needing many points to create a custom shape. If I could do this with the actual clip envelope then that would be amazing, but even with an automation envelope it would potentially be a time saver if the transition is tricky. And when I have 20-30 different points of automation on a single vocal already... do you think they want to put down another node and right click to change the shape? When they could just grab and move the shape?
 
And this isn't even getting into synth automation. If you're looking for a particular movement in sound for say automating a filter cutoff, having different envelope shapes would be another huge time saver for fine tuning your sound.
 
These are just some thoughts/ideas to consider. Think it over and let me know what you think?

theheliosequence
I honestly doubt that the calculation would take much more effort than it would to simply change from linear to fast or slow. I'm not sure why you would make that speculation or assume that it would be a deep processing burden. We can draw LFO automation in seconds, without the CPU flinching... we can calculate transients nodes, instantly... And you think we couldn't change the shape of automation without a CPU hit? A Do you have any evidence or knowledge to support this? I'm honestly curious why you've suggested this, as I have no background in DSP processing/calculation.

Given the amazing power of modern processors, I could be wrong about how much of a burden this would impose, but as a math guy I can tell you that calculating a polynomial curve to smoothly fit three points with slopes at both ends that match the preceding and following slopes/curves (which might also be polynomial) and recalculating it continuously as one of the points is moved in two dimensions is a much more significant task than rendering a pre-defined logarithmic/exponential curve between two points. If you were to string a bunch of these custom polynomial curves together and wanted each to bend smoothly into the next, you'd have a real mathematical challenge on your hands. No doubt there are function libraries out there to help a programmer implement something like this, but at a certain point, I think you would have to enforce some limitations on how many of these curves you link in succession.
 
As I said before, I'm open to hearing examples where the generic curves are audibly insufficient. At this point it's all hearsay for me, but I understand that my ignorance is not your problem, and it might be too much of a burden to school me. 
 
If there really is a requirement that just can't be met without using a lot of nodes to get just the right curve, I would probably propose adding a limited number of additional curve types using other easily calculated functions to meet that need rather than trying to implement the more unlimited kind of customization you're proposing.
 
If there's a DAW out there that does his already, then I would say SONAR might need to step up and compete, but if not, I think SONAR should only lead if there's a demonstrable and widespread need for more flexibility (pun intended).