Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Closed Issue

Automation Ripple Issue Tools
issueid=17 06-13-2009 06:27 AM
Human being with feelings
Automation Ripple
Automation moves randomly

Automation envelopes move to places where they don't belong when other clips containing automation are moved around.

Issue Details
Issue Type Closed Issue
Project Deprecated REAPER issue tracker
Category Editing behavior
Status Fixed
Priority 1 - Highest
Affected Version 3.02
Closed Version 3.06
Yes votes 8
No votes 0
Assigned Users (none)
Tags (none)

06-13-2009 10:05 PM
Administrator
 
Any suggestions on desired behavior? I.e. destroy automation that you move over, or combine (average)?
Reply
06-13-2009 11:32 PM
Human being with feelings
 
I would say:

if in FIPM or using "Items always mix" for the project then it should combine (average) when overlapped.

if in the non-mixing exclusive/tape mode then it should replace whatever happens to be immediately underneath it. I don't think it would be happy for the automation to be wiped out in the items wake as it's dragged along. Rather as it's dragged it should always replace only the automation directly beneath it as it is positioned or until it is dragged past at which point the old underlying automation should return.

Sorry if that's not entirely clear.
Reply
06-14-2009 04:42 AM
Human being with feelings
 
In FIPM I would "preference" it. One FIPM preference should be to leave existing automation in place when moving an envelope over an existing one.

Example: FIPM of vocal takes to line up phrases. The envelope shouldn't move on every little timing shift of any clip. Or if I duplicate (or move) a clip from chorus 3 to chorus 2 and it kills the automation I'd just written for chorus 2. In that case I don't want the envelope moving with the part so maybe a key modifier to leave the envelope on move?

But under ordinary circumstances yes, destroy. This will probably play into the "precedent" play behavior that Airon talks about. If a part has precedence it's automation should play? If you move a part and it has automation and it moves to be "on top" then yes, it's automation should destroy existing envelopes.

Either way, under no circumstances should automation move vertically by itself - without it's clip - and and end up at a place where it wasn't intentionally written.

Quote:
Originally Posted by plush2
I don't think it would be happy for the automation to be wiped out in the items wake as it's dragged along. Rather as it's dragged it should always replace only the automation directly beneath it as it is positioned or until it is dragged past at which point the old underlying automation should return.
+1. Replace or modify on drop only.

Anyway, I don't see the value in an average. If I move a clip with automation and that clip will play by itself, I want it's automation, not an average of it and something else that has nothing to do with it.

Think about loop based production. Automate a loop and duplicate/move clips? You want the exact automation you'd written on every copy. Not different averages of it depending on where you drop it.
Reply
06-14-2009 07:14 AM
Administrator
 
OK, so we could all live with the automation being replaced on drop then?
Reply
06-14-2009 08:21 AM
Human being with feelings
 
Probably :)

Here are a few scenarios of moving a clip (the green one) and the automation and a few "rules of thumb":

[IMG]http://img197.**************/img197/7374/r302dsenvmoves03.th.png[/IMG]
Big pic:
http://img197.**************/img197/7...envmoves03.png

-- whenever a clip is moved the envelopes and segments for its neighbouring clips (at both is original position and destination position) must not change - this may mean creating additonal points at its original start and end or retaining the first and last points (that might be easier). See track 2 for a point created at 9.1.00.

-- when a clip is dropped into an empty position (e.g. at 6.1.00 on track 2) any existing automation is replaced, but additonal points may need to be created to keep the neighbouring envelopes unchanged

-- any envelope points or segments between the original and final positions of the moved clip must not change at all

-- when a clip is dropped in a postion where there is already (part of) a clip (e.g. at 5.1.00 on track 4) there are three options: a) keep any existing automation at the destination position, b) apply the automation moved with the clip, c) average the automation (as on track 5). I think that the averaging would be too problematic - taking into account possible different envelope shapes, point positions etc. For me the default would be (b) apply the automation momved with the clip. If I want to keep the automation alredy at the destination position I would unlink "move envelope points with media items", or, better, have a modified drag function (Alt+drag?).

-- when a clip is moved from a position where is (partially) overlaps another clip (e.g. track 6, moving ofrm 5.1.00 to 6.1.00), then the automation should be kept at the oriignal position.

Added fun:
-- moving a clip with multiple envelopes
-- moving multiple clips with envelope points :shock:
Reply
06-14-2009 08:46 AM
Human being with feelings
 
I could certainly live with that.

You may wish to provide an automatic disengagement of 'Envelope points move with media items' status, but only for the tracks that are in FIP mode. It is much less likely that anyone will want concrete track automation to stick to individual items when the user is shuffling multiple items on top of one another and create a comped version of vocals for example. The FIP mode is so different from the normal track mode that this distinction would be an excepted behaviour right away.

What happens when an item is dropped in from another track ?

If the target is in FIP mode, the automation is not pasted in. Otherwise it is. Lawrence, do you think that would be a good default for your type of work?

Overlap behaviour.I can think of two ways so far.

Replacing the automation in the overlapping area with automation from user-selected item(which also plays in to the underlap behaviour of left-item on right-item movements).

Or interpolate the automation of the selected item and the overlapped item in the crossfaded area. The result cannot be undone by moving one item out of the crossfade area, unless you'd like to keep two automation playlists every time there's a crossfade. One advantage of interpolation across the crossfade area is the cutting down on automation envelops values doing large jumps at the cut/insert locations.

What happens when you drag an item out of a crossfade with another ?
The automation in the crossfade area is kept intact and the moved item takes a copy of it along with it. That way you'll get the same result in the item you're moving as before(for the most part).

-edit-

An interesting possiblity to consider is to interpolate the automation values of the dropped in material to the ones outside of it by a preset amount around the cut/insert locations, optional of course. That way, plugins that handle large value jumps badly could be behave a little better. I'm not sure I'm overdoing this, but options could tell Reaper whether to interpolate outside the selected item, interpolate so this crossfading of automation ends up having its centre where the items meet, or inside the selected item. Fun, ain't it :).

This 'interpolate all automation from point A to point B of a timeselect and track selection' could be a good separate function as well. It would generate automation points at point A and point B and erase all inbetween. That would be a manual way of smoothing out automation, and has quite a few creative users as well.
Reply
06-14-2009 08:58 AM
Human being with feelings
 
FIPM is a different beast from what I'm accustomed to so I'll go along with whatever you guys think is best. There are so many different possible circumstances it's confusing.

I do think a key modifier would be handy to override moving the envelope in some cases. Shift-Move = no envelopes moving with it. As long as automation doesn't end up somewhere it wasn't intentionally written I'm good with it.
Reply
06-14-2009 10:06 AM
Human being with feelings
 
+1 for a key modifier
Reply
06-14-2009 10:16 AM
Human being with feelings
 
Quote:
Originally Posted by Lawrence
Example: FIPM of vocal takes to line up phrases. The envelope shouldn't move on every little timing shift of any clip. Or if I duplicate (or move) a clip from chorus 3 to chorus 2 and it kills the automation I'd just written for chorus 2. In that case I don't want the envelope moving with the part so maybe a key modifier to leave the envelope on move?
I think that should be tied to the toolbar icon that doesn't really do anything yet:


when lit. move envelope points with the items, replacing corresponding values at the destination.
When it is not lit... leave the automation behind. Isn't that what it's for?

greetings
.t
Reply
06-14-2009 11:07 AM
Human being with feelings
 
Quote:
Originally Posted by Tallisman
I think that should be tied to the toolbar icon that doesn't really do anything yet:


when lit. move envelope points with the items, replacing corresponding values at the destination.
When it is not lit... leave the automation behind. Isn't that what it's for?

greetings
.t

True... with caveats.

Currently it only works on the same track anyway, moving an item to another track doesn't take the envelope with it whether that icon option is on or off. And it only works when there are nodes directly under an item - and then only halfway - so it's broken in a few different places.

Draw a flat -50db volume line under a clip where the nodes are outside of the clips borders and move the clip, and watch what happens. It doesn't take that volume level with it under any circumstances that I can see. Similar happens when there is only one node under an item. A ramp that goes from there to a node outside of the clip range gets changed when you move it, as the ramp now goes to a different node outside of the clip range which may be at a different level, different ramp angle for the envelope now.

When you move a clip, new nodes should be created/snapped on the clip edges to retain the true shape of the envelope beneath it. It doesn't do that. It's the "item" (node) paradigm being executed here again as opposed to the "range" paradigm that's more logical and repeatable.

Notice the nodes below are outside of the clip range. No matter where I move it, it retains the exact same envelope. Reaper doesn't do that. If there are no nodes beneath a clip it just picks up the current envelope level/shape of where it's dropped.




That has serious implications for FX automation as we tend to set the FX (eq change?) *before* the clip, and put it back *after*. Move it - the clip with no nodes beneath it - and lose it.

So it's currently (the icon and the function) "move nodes with item" in practice, not really move "envelope" with item. No nodes there, nothing moves.

But yeah, when all that other weird stuff is sorted out... use the icon or a KC tied to it to defeat moving. Once moving actually works correctly.
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 04:28 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.