[Ardour-Dev] Some editing hints wanted

[fons at kokkinizita.net]

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 ? 
 
Ciao,

-- 
FA

There are three of them, and Alleline.