[Ardour-Dev] Some editing hints wanted

[fons at kokkinizita.net]

On Thu, Sep 16, 2010 at 02:01:40PM -0400, Paul Davis wrote:

> 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.

??? How ?
 
> > 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?

All tracks have been recorded simultanuously, they all have the same
start and end point. What more is required to make them 'equivalent' ?

> > - 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

If the screen is filled you can't even start the selection: there is
not point above the first track to click into.

> > - '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.

So *how* do I select all regions at either the playhead or the mouse
position (you may assume they are all 'equivalent') and nothing else ???

And why, if A and B are separated by a millisecond, 'u' selects either
A or B (depending or where I click), but when I move B so it overaps A
it selects both ? Does the 'edit range' depend on this overlap ? Again,
I've tried to understand what Ardour is doing in such cases, but it just
does not make any sense at all.

> > - 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 ...

That is not the question. The question is why e.g. clicking on the first
B region selects it correctly, and Shift-click on the second B region
selects and adds *both* the A and B regions on that track.

> > 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
> keybindings.
> 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).

which means that is useless in this case.

> > 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.

Note that the 'primitive' hard-disk editors that I was using in
the late 1980's had no problem with any of the things I mentioned.
And they did not even have any form of  'graphical' representaion
of the tracks. But you could edit using them almost as fast as using
a razor blade on tape. The only time wasted was the transfer from DAT
to hard disk, but that could be done while you had lunch or a coffee.

The fundamental problem here is that Ardour is completely unaware of
what a user is trying to achieve. It provides elementary operations
much in the same way as an assembler provides machine instructions.
But it has no idea at all of higher level concepts, such as 'the user
is trying to make an edit (short crossfade) between two sets of regions'.
Apart from the selection there is no 'context' to any edit operation,
and consequently no intelligence either.

Ciao,

-- 
FA

There are three of them, and Alleline.