<p>It isn't a perfect solution, but you can use nested sequences in order to apply your edits separately from your speed changes.  This way the speed changes impact the final video instead of just one clip.</p>

CC BY-SA 3.0
2014-05-02T19:27:40.440Z
2014-05-02T19:27:40.440Z
AJ Henderson
<p>Your screenshot does not have sufficient zoom to see how the checkpoints of <em>Velocity</em> envelope behave. Let me assume they are all having Transition of <em>Hold</em>, e.g. <em>velocity</em> changes abruptly, <strong>not gradually</strong>: <code>100%</code> immediately to <code>150%</code>, then immediately back to <code>100%</code>.</p>

<p>Along the course of my experience with Vegas, I found <em>velocity</em> envelope inefficient. Instead, I find splitting <em>Video Event</em> into several ones more effective, and here's why.</p>

<p>Say, you have a video event of length <code>1 minute</code>, as on Track 1. Say, you want the original timeline <code>0:20</code> till <code>0:30</code> to play at <em>Velocity</em> of <code>200%</code>, so that it took only <code>5 seconds</code> instead of <code>10</code> original.</p>

<p><img src="https://i.sstatic.net/PE3uF.png" alt="Vegas screenshot"><br>
Full scale image <a href="https://i.sstatic.net/PE3uF.png" rel="nofollow noreferrer">here</a></p>

<p>If you add a <em>Velocity</em> envelope as in Track 2 (<code>200%</code> at timecode <code>0:20</code>), you would need to <strong>guess</strong> at which point to put another control point for <em>Velocity</em> so that playback continued at original speed.</p>

<p>Also, the end marker of the video indicates that the actual timeline ends at approx. <code>0:54</code> (and the rest is a repeat of the same video event from the beginning).</p>

<hr>

<p>However, if you take another approach and <strong>split</strong> your video as displayed on Track 3 and then <kbd>Ctrl</kbd>+<kbd>drag</kbd> the end point of the middle <em>Event</em>, it would work smoothly. You will be <strong>sure</strong> that the third <em>Event</em> starts at proper timecode (in original scale).</p>

<p>The only thing you would need is dragging the 3rd <em>Event</em> backwards, as shown in Track 4.</p>

<p>Moreover. As soon as you <em>Group</em> all three <em>Events</em> by <kbd>Ctrl</kbd>+<kbd>clicking</kbd> them and then pressing <kbd>G</kbd>, you will be able to process them together. In Track 5, I have stretched all three events so the entire video played a bit slower.</p>

<hr>

<p><strong>Note 1.</strong> Most likely, you will need to overlap these three <em>Events</em> somehow. This will let the stream to be smoother, without abrupt <em>Velocity</em> changes.</p>

<p><strong>Note 2.</strong> Of course, all above applies to multi-track <em>Groups</em> as well. You need not keep all <em>Events</em> within the same <em>Track</em>.</p>

CC BY-SA 3.0
2014-05-09T23:42:22.797Z
2014-05-09T23:42:22.797Z
Be Brave Be Like Ukraine
<p>I have to stitch various pieces of footage together, and the final result will be about 1–1.5 hour long.</p>

<p>Because of all the needed changes (blurring faces, inserting images and icons in certain places, synchronising the footage pieces among each other and fading them out\in with right timings etc), my project map starts to look like <a href="https://i.sstatic.net/MWwZd.png" rel="noreferrer">this</a>. The #3 and #4 tracks are just transitions from one piece to another. In tracks #1 and #2 is how most tutorials tell to deal with blurring\changing a screen area (duplicate the track above itself and then pan\crop the duplicate).</p>

<p>The problem is that in multiple places the video also has to be sped up\slowed down, and when I do it, the footage length changes like a fractal curve, and all the alignments get messed up. And besides <em>these</em> speed changes, the whole eventual video has to be sped up again once more too (x1.5).</p>

<p>This looks like one of those things that I’ll be cursing myself about later, because a simple and overlooked mistake led to losing huge amounts of time\work, so I decided to just ask about it now: am I doing it wrong, and if so—what’s the more productive way of dealing with many playback speed changes in relatively big editing projects?</p>

CC BY-SA 3.0
2014-04-29T23:29:49.233Z
I don't know Vegas unfortunately, but does it support nested sequences/timelines?  If so, you could apply the edits separately from the speed changes.  The transitions also seem to be a weird and atypical way to do them, but maybe it's a limitation of Vegas.
AJ Henderson
CC BY-SA 3.0
2014-05-02T19:19:57.040Z
AJ Henderson: I don’t know why, but it didn’t work at first, right after I saw your reply. The markers were still getting messed up. Now, however, nesting the project as a single track does work. Would you kindly resubmit your message as an answer, so I’ll admit it and mark the question closed?
Imfego
<vegas-pro>
What is the productive way of doing multiple speed changes in a video editing project?
Imfego
# What is the productive way of doing multiple speed changes in a video editing project?

(Asked by: username_0 on 2014-04-29)

I have to stitch various pieces of footage together, and the final result will be about 1–1.5 hour long.

Because of all the needed changes (blurring faces, inserting images and icons in certain places, synchronising the footage pieces among each other and fading them out\in with right timings etc), my project map starts to look like [this](https://i.sstatic.net/MWwZd.png). The #3 and #4 tracks are just transitions from one piece to another. In tracks #1 and #2 is how most tutorials tell to deal with blurring\changing a screen area (duplicate the track above itself and then pan\crop the duplicate).

The problem is that in multiple places the video also has to be sped up\slowed down, and when I do it, the footage length changes like a fractal curve, and all the alignments get messed up. And besides *these* speed changes, the whole eventual video has to be sped up again once more too (x1.5).

This looks like one of those things that I’ll be cursing myself about later, because a simple and overlooked mistake led to losing huge amounts of time\work, so I decided to just ask about it now: am I doing it wrong, and if so—what’s the more productive way of dealing with many playback speed changes in relatively big editing projects?

**Tags:** vegas-pro

> **Comments:**
> **username_1**: I don't know Vegas unfortunately, but does it support nested sequences/timelines?  If so, you could apply the edits separately from the speed changes.  The transitions also seem to be a weird and atypical way to do them, but maybe it's a limitation of Vegas.  
> **username_0**: username_1: I don’t know why, but it didn’t work at first, right after I saw your reply. The markers were still getting messed up. Now, however, nesting the project as a single track does work. Would you kindly resubmit your message as an answer, so I’ll admit it and mark the question closed?  

---

## 2 answers

### Answer by username_1 on 2014-05-02. Score: 1 | Accepted answer

It isn't a perfect solution, but you can use nested sequences in order to apply your edits separately from your speed changes. This way the speed changes impact the final video instead of just one clip.


---

### Answer by username_2 on 2014-05-09. Score: 2

Your screenshot does not have sufficient zoom to see how the checkpoints of *Velocity* envelope behave. Let me assume they are all having Transition of *Hold*, e.g. *velocity* changes abruptly, **not gradually**: `100%` immediately to `150%`, then immediately back to `100%`.

Along the course of my experience with Vegas, I found *velocity* envelope inefficient. Instead, I find splitting *Video Event* into several ones more effective, and here's why.

Say, you have a video event of length `1 minute`, as on Track 1. Say, you want the original timeline `0:20` till `0:30` to play at *Velocity* of `200%`, so that it took only `5 seconds` instead of `10` original.

![Vegas screenshot](https://i.sstatic.net/PE3uF.png)  
Full scale image [here](https://i.sstatic.net/PE3uF.png)

If you add a *Velocity* envelope as in Track 2 (`200%` at timecode `0:20`), you would need to **guess** at which point to put another control point for *Velocity* so that playback continued at original speed.

Also, the end marker of the video indicates that the actual timeline ends at approx. `0:54` (and the rest is a repeat of the same video event from the beginning).

---

However, if you take another approach and **split** your video as displayed on Track 3 and then `Ctrl`+`drag` the end point of the middle *Event*, it would work smoothly. You will be **sure** that the third *Event* starts at proper timecode (in original scale).

The only thing you would need is dragging the 3rd *Event* backwards, as shown in Track 4.

Moreover. As soon as you *Group* all three *Events* by `Ctrl`+`clicking` them and then pressing `G`, you will be able to process them together. In Track 5, I have stretched all three events so the entire video played a bit slower.

---

**Note 1.** Most likely, you will need to overlap these three *Events* somehow. This will let the stream to be smoother, without abrupt *Velocity* changes.

**Note 2.** Of course, all above applies to multi-track *Groups* as well. You need not keep all *Events* within the same *Track*.


---

