Ableton adding in automation points at start/finish when moving the data

[steveandthesea]

Sorry the title is a bit confusing but I don't know how else to describe this.

I've got a bunch of songs that use a lot of automation, and I'm adding them into a "setlist" project. Each of these songs have multiple tracks, instruments, effects etc, and I've used automation to turn everything on at bar 3, then off at the end of the song. This is to avoid parts of different songs overlapping and to save on CPU as the setlist builds up with plug-ins and whatnot.

Whenever I add a new song into the master setlist, it gets dropped in at the start. Fine, no problem, but when I then drag that song over to where it should be, Ableton adds in alternative automation data. So now something that was supposed to switch on at bar 3 now turns on at bar 1, then off for 2 bars before it should start. See below:



1. here you can see 2 automation tracks of "Device on". They are both set to off at the start, then turn on at bar 3, then off again at the end of the song.



2. I drag the track a little along the timeline. Now the devices are set to start in the on position, turn off for a brief moment, then off again at the end and then on again. The on status at the start and end has just been added by Ableton, and I don't want it...

...what's going on here?

TIA.

[scg]

Obviously there was never an answer to this, and presumably this isn't something that causes people much trouble. But, I've encountered it as well. It appears that dragging a clip will (in some cases at least) not only move its associated automation points (assuming automation isn't locked), but will also insert new automation points that can have the effect of changing the automation throughout the rest of the track. For example, an effect could be off at bar 50, and after dragging a clip from bar 25 to bar 24, the effect is now on at bar 50. I've noticed other cases where automation edits can have similar effects.

I realize this isn't something that's likely to change, but it seems like edits such as dragging clips shouldn't affect automation outside the affected range. In any case, one workaround seems to be to cut and paste instead, which doesn't seem to have the same behavior.

[pottering]

Obviously there was never an answer to this, and presumably this isn't something that causes people much trouble. But, I've encountered it as well. It appears that dragging a clip will (in some cases at least) not only move its associated automation points (assuming automation isn't locked), but will also insert new automation points that can have the effect of changing the automation throughout the rest of the track. For example, an effect could be off at bar 50, and after dragging a clip from bar 25 to bar 24, the effect is now on at bar 50. I've noticed other cases where automation edits can have similar effects.

I realize this isn't something that's likely to change, but it seems like edits such as dragging clips shouldn't affect automation outside the affected range. In any case, one workaround seems to be to cut and paste instead, which doesn't seem to have the same behavior.

"assuming automation isn't locked"

?

That's the point of locking automation, you lock it so it doesn't move with the Clips, it has no other function.

It adds automation points to preserve the shapes before and after the selection you dragged from, and before and after the new place you dragged the selection to.

[scg]

Irrespective of whether there are issues with the behavior (there may not be), you're misunderstanding. There's no confusion about what locking does, and it's tangential to the discussion.

As for this:

It adds automation points to preserve the shapes before and after the selection you dragged from, and before and after the new place you dragged the selection to.

Yes, that's the expected and desired behavior. What the OP seems to be describing, and what I think I've seen also, is that sometimes that doesn't happen - instead, automation points are added that change the automation outside the affected range (as in the OP's screenshots).

To be clear, there may very well be a logical explanation, or it could be user error on my or the OP's part. But no one is confused about automation locking, and I'm not sure what specifically you were objecting to there.

For what it's worth, I can reproduce the behavior in a minimal project. However, I'm only seeing the behavior in one case, which is on/off automation for racks. I can't reproduce it for any other kind of automation. I don't know if the OP was automating racks specifically, but that's the only place I'm seeing the behavior. Maybe it's an idiosyncrasy, or maybe there's a logical explanation and it's the expected behavior.

[scg]

For anyone who cares, I played around with this a bit more, and it seems not to be related to the type of automation, but rather to how the automation was created - it seems to require a particular sequence of automation edits in order for it to occur. As such, my guess is that if it's an idiosyncrasy (which it may not be), it's one that users are very unlikely to hit. The OP happened to hit it, and I happened to hit it at least once, but it doesn't seem like something many users are likely to encounter.