Reworked the push/pull trimming

This commit is contained in:
Ed Ward 2017-02-27 09:14:22 +01:00 committed by Len Ovens
parent 4e3479eea4
commit a7adc7aaa9
7 changed files with 34 additions and 28 deletions

View File

@ -1,36 +1,42 @@
<p>
Normally, when you trim regions by dragging with the mouse, it affects
Normally, when trimming regions by dragging with the mouse, it affects
only the selected regions. Their lengths are directly affected by the
trim operation, but nothing else is. Sometimes though, you might like
to trim a region that directly adjoins another, and keep this relationship
the same&mdash;you are not trying to make one of the regions extend
over the other&mdash;you would like the junction to move in one
direction or the other as part of the trim. This requires trimming both
trim operation, but nothing else is. Sometimes though, when trimming a region
that directly adjoins another, the desired result is to move the boundary
between the regions and not to make these regions overlap. This requires trimming both
regions on either side of the junction, in opposite directions.
<dfn>Push/Pull trim</dfn>, activated by pressing shift key before
starting the drag, will do just that. Here's a few pictures to show the
difference in the results of a normal trim and push/pull trim. First,
the initial situation:
<dfn>Push/Pull trim</dfn>, activated by pressing <kbd class="mod3n"></kbd> key before
starting the drag, will do just that.
</p>
<img src="/images/a3_before_trim.png" alt="region arrangement before trim" />
<p>
Here is what happens after we trim the right hand (selected) region by
dragging its starting position earlier:
</p>
<img src="/images/a3_after_trim.png" alt="region arrangement after a trim" />
<p>
You can see that it now overlaps the earlier region and a crossfade has
been created between them.
</p>
<p>
Lets look now at what happens if we do the same trim, but <kbd
class="mouse mod3">Left</kbd>-dragging to turn it into a push-pull trim instead:
</p>
<img src="/images/a3_after_push_trim.png" alt="region arrangement after a push trim" />
<p>
There is no overlap, and the end of the earlier region has been moved
along with the start of the later region, so that they still directly
adjoin each other.
The following pictures show the difference in the results of a normal trim and
a push/pull trim:
</p>
<figure>
<img src="/images/before-trim.png" alt="region arrangement before trim" />
<img src="/images/after-trim.png" alt="region arrangement after a trim" />
<img src="/images/after-push-trim.png" alt="region arrangement after a push trim" />
<figcaption>
Trimming vs. push/pull trimming. Before trimming, After a simple trim, After a push/pull trim
</figcaption>
</figure>
<p>
In the initial situation, before trimming, two adjascent regions are present,
the rightmost-one being selected.
</p>
<p>
The simple trim, obtained by dragging the selected region's starting position earlier, overlaps
the earlier region. A crossfade has been manually created between them, so their
sound will fade from the leftmost region to the rightmost one.
</p>
<p>
If the same trim is done, but by <kbd class="mod3n"></kbd><kbd class="mouse">Left</kbd>-dragging
to turn it into a push-pull trim instead, there is no overlap, and the end of
the earlier region has been moved along with the start of the later region, so
that they still directly adjoin each other. In effect, it is like doing a simple
trim to reduce the leftmost region, then doing a simple trim to extend the rightmost
one to fill the gap.
</p>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 2.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.5 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 2.2 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.5 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.3 KiB