]We make TV promos. And quite often a promos body of a script will remain the same, but the information (day) will change.
So the way we work is to have a Vox lane, and what we call version lanes(SP for specific day, TM for tomorrow…) there are time when this information is at the top of the promo and at the end. So to eliminate the chance of pairing a tuesday with a tomorrow we Group this information together. and drag these to the Vox lane as needed.
Works great…except when automation follows events is on.
To demonstrate i have include some screen shot with exaggerated automation
the before JPEg shows a SP version(clips “vox 18 +19”) with the automation required for a promo. The after shows "automation follows events turned on, and the tx version (clips "vox 20+21) dragged up to the Vox lane . As you can see it has wiped all of the automation. It has infact travelled with the SP version.
Really annoying, and goes away when we turn off automation follows events. we want automation to follow the events we move , not everything in between.
Might sound like a dumb question, but is there any particular reason for doing it your way?
When I’ve done this sort of stuff, and I’ve done a lot of it, I’ve just created a master version and then copied that over to the next logical location on the timeline. So if the promo is a 60, then if version A is at 01:00:00:00 version B follows at 01:02:00:00 for example. That way, with cycle markers set, I can easily export all of them at once. That’s very handy if stuff remains the same for all of the “information” but they decide the “body” actually should change. Doesn’t happen all that much, but it does happen for me.
Alternatively you could use tracks instead of lanes of course.
We do it all at the same time code. not at individual timecodes per version, it is way faster. And gives the versioners something to do. And I did mean tracks sorry, not lanes. Wrong terminology.
Ah, I see what you mean now. Your request makes absolute sense.
I would either label the thread [BUG] or [ISSUE] (whatever the “accepted” nomenclature is) or post this in the feature request section.
PS: I still think laying it out over time is faster. I used to do that with a bunch of travel advertising spots, but whatever floats your boat of course. An additional workaround would of course be to move the “body” down between the two events that change, and then move it all back up. But that’d be two moves, so you might as well just move the top/head independently instead which also doesn’t destroy automation…
Thanks, our system has evolved over many years as we deal with an ever changing myriad of versions, reversions, lengths and tweaks. Editors can lay 5 or 6 different cuts on one time line, each with multiple versions of headers and tails and sometimes rather complex automation. The script will change, the times will change etc. Many different sound operators will have to be across each others projects as marketing change their minds, and this system is robust and easy to manage.
Our point was simply we found that moving grouped (or any multiple selected discontiguous clips/events/segments) will destroy any automation that existed between those segments, which renders the “automation follows events” option near useless in actual daily operation.
And yes, we should flag as a bug.
I’ve had a look at this and I wouldn’t necessarily flag it as a bug. I can see the argument that if you move each event individually then why does moving multiple selections at the same time produce a different result but it’s treating it more like a range with the multiple selection.
As I don’t know your exact scenario (do the other tracks contain automation? - if it’s only a starting node then just get rid of it as you imply that automation isn’t needed as you can disable automation follows events) there are a variety of workarounds:
- Make use of track versions for your additional tracks and switch between them keeping automation intact
- The “automation follows events” button is pretty clear so it’s not a huge deal to click to toggle on/off or use a key command
- Lock the automation lane on the main track
- Automate a VCA fader instead and don’t worry about track automation
True, there are many workarounds which we have been doing. (but lets not open the VCA debate again)
Or, it could work like logic would dictate. As other DAWs do.
Or, they could rename the option to “Automation follows events and also arbitrarily move some other stuff that wasn’t selected”
Of course the example given is a simplified example to highlight the behaviour.
For example (off the top of my head), I had an I/V between 2 people that was originally cut on one track by an editor, and then retrospectively decided I wanted to move one subject onto it’s own track (say to apply a different plugin to one person), the only way would be to move each individual edit separately, as doing more than one selection would destroy the first automation pass on everything.
What use is grouping clips or multi-select if it moves ungrouped/unselected automation?
