[Ardour-Dev] Some editing hints wanted
fons at kokkinizita.net
fons at kokkinizita.net
Sat Sep 18 15:14:09 PDT 2010
On Thu, Sep 16, 2010 at 05:09:23PM -0400, Paul Davis wrote:
> > All tracks have been recorded simultanuously, they all have the same
> > start and end point. What more is required to make them 'equivalent' ?
> when you say that the track won't join the group, do you mean (a)
> selecting another track in the group doesn't select this one and/or
> (b) selecting a region in another track in the group doesn't select an
> (apparently) equivalent region in this one and/or (c) it simply
> refuses to even be a member of the group at all (i.e. the "g" button
> shows no group membership) ?
All tracks are a member of the group, as shown by the menu opened by
the 'g' button. All tracks have been recorded simultanuously, so
regions should be equivalent. When I click on a region in the b-format
track it gets selected, but the equivalent others are not. If I click
in a region in any other track it an all equivalent regions are selected,
except the one in the b-format track.
> > 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.
> see above, and i'll await clarification.
This is a completely different issue, not related to edit groups.
I try to select all equivalent regions manually by:
- clicking in one of them
- Shift-click in the others to add them to the selection.
The first click works as expected, it selects the region I want.
The others (with Shift) select both the region I want, *plus* one
that overlaps it. So apparently 'Shift' does not just mean 'add
to selection', but it also changes the rules of the selection.
> i'd also like any suggestions you have on the "have to be extremely
> careful where you click" situation that you described. i'm not aware
> of this as an issue, but i'd welcome clarification on how its hurting
> you and how you'd like to see it improve.
There are two issues here:
- When trying to trim the end of the 'A' regions (left of the wanted
xover point), sometimes a click triggers the 'trim start point' action.
This happens even if only the final 0.1% or less of the region is shown
on the screen - nobody would try to trim the start in that case so this
action should just be disabled in those cases.
- At the other end (the B region, right of the wanted xover point)
trying to trim the start often leads to the region being moved.
The reason for this is probably that the choice between 'trim start'
and 'move' (as shown by the cursor shape) is made in a way that gets
confused by the presence of the region name in the coloured bar below
the waveform. Just try moving the mouse pointer there: the cursor
switches almost randomly between the two actions when moving over
the text. I suspect the choice is made based on pixel color rather
than on vertical position.
> if someone (such as yourself) carefully defines such workflow
> situations, then work can be done to support it. without a clear model
> of what "high level concepts" are required, there's not much point
> trying to implement specific high level support for them.
I've been thinking a lot about how to describe them. It's quite
different from anything based on 'regions', and more about 'ranges'.
Which leads to my final question for now: how do I use the 'range'
editing ? I've tried it, I can select a range, but none of the
editing action (cut, copy, paste) seem to do anything with it.
What am I missing ?
There are three of them, and Alleline.
More information about the Ardour-Dev