[Ardour-Dev] Some editing hints wanted
paul at linuxaudiosystems.com
Thu Sep 16 11:01:40 PDT 2010
On Thu, Sep 16, 2010 at 1:39 PM, <fons at kokkinizita.net> wrote:
> Could be done in this case. It would be tedious if you have more
> tracks and not help much if the total length of the recorded takes
> is much more than the wanted result. The real solution to this
> would be the ability to switch between at different timelines/sets
> of playlists, all of them using the same track layout an feeding
> the same mixer strips. Just two would be fine, one to copy fragments
> from and the second to assemble them.
you can already do that.
>> >This is quite tedious, in particular as each step also
>> >requires selecting all tracks, making sure they dont move
>> >relative to each other, etc. The last three steps are
>> >required only to undo the unwanted side effect of the first.
>> as paul said, i find edit groups to be the bee's knees.
> Except that here they don't work correctly. The B-format track
> refuses to behave as part of a group, in all six sessions I
> created. Adding it manually to a selection produces the problem
> explained below.
please explain more about this behaviour. i suspect that what is
happening is that the b-format track doesn't meet the criterion for
"edit group equivalency" that is applied to regions. the region there
is probably not judged as equivalent-enough to the regions in the
other tracks. what is the history of this track?
> - Selecting a rectangle: this works, provided you can see all
> tracks and there is some empty space for the first click.
yes, vscroll-during-select has been on the TODO list for a long time
> - 'U' (select at edit point): once A and B overlap (and they
> have to, it always selects both. I don't understand the
> logic behind this.
that is not what "u" is bound to. it selects anything that has some
presence within the current edit range.
there is no select-at-edit-point.
> - Select first track of A or B by just clicking on it, the others
> with shift to add to the selection: the first works, all the
> others select both A and B if they overlap. The method is
> useless anyway if you have more tracks than fit vertically
> on the screen - having to scroll just makes thing worse.
the question is whether you're happy working with off-screen tracks
being edited ...
> This also means that it's often impossible to separate A and
> B again without selecting and moving individual tracks of B
> and then re-aligning them.
> Assuming you can get the required selection, it's all to easy
> to modify it accidentally. The operation you want to do are:
> - trim the end of A,
> - trim the start of B,
> - move B.
> All three of them can modify the selection if you are not
> *extremely* careful where you click, and that usually
> means something has been moved and should be undone.
> Also you don't want to move A in any case (this would
> destroy a previous edit), but it's all to easy to do this.
how would you want to do this that avoid the "extremely careful" part?
> Another problem is that the only way to do any of these
> is by 'visual' operations. There is no way to say e.g.
> 'add 10ms to A' or 'move B by 5ms'.
you can't change the length of a region like this, but you can change
its placement using the nudge clock and the nudge buttons or
you can change its length with absolute precision in its region
editor, but this will not map across all selected regions (since the
region editor is specifically for editing a particular region).
> Aother fundamental thing that's missing is the ability
> to listen to either the end of A or the start of B
> separately without having to move them apart again.
sounds like an interesting feature request. you can listen to A or B
on its own, but not the "end" or "start" of either.
More information about the Ardour-Dev