[Ardour-Dev] Some editing hints wanted

Paul Davis paul at linuxaudiosystems.com
Thu Sep 16 14:09:23 PDT 2010

fons, it would help if you could stop generalizing quite so much.

i entirely understand and agree that for the specific workflow you're
describing, some work needs to be done. its really useful to get a
good understanding of what that work is.

but ... watch the video of armand klenk of SAE editing with Ardour at
tonmeistertagung in 2008, and it becomes a bit fallacious to talk
about "problems with selection and editing" as a *general* case. i'm
entirely open to the idea that ardour currently supports a workflow
that isn't used much (though that would need to be proven, and i'm not
sure how one would do that), and clearly your example is an existence
proof that, at least given your current knowledge and understanding
and the current lamentable documentation, ardour doesn't provide good
ways to do what you need to do. so lets try to focus on what is
necessary rather than over generalize into imagined conclusions about
what everyone does. if i've learnt one thing after 10 years on this
application, its that no two people actually work in the same way,
even when the final goal is the same.

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

click the "p" button of each track for playlist operations.
however: what is definitely missing here (and even more so in ardour2)
is a sensible way to get to map across edit groups etc. sampo did add
some limited support for this a couple of years ago, but its still not
what i would call a manageable take system.

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

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

range selections do not require blank space. they can be directly on a track.

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

as noted, there is no operation to select "all at edit point". if you
select a region in one track of an edit group, it should select all
equivalent regions in all members of the active group.

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

There is an option under Options->Misc called "Region equivalents
overlap". This allows a choose of two different region equivalency
models, best expressed (to you, at least) as code:

Region::overlap_equivalent (boost::shared_ptr<const Region> other) const
	return coverage (other->first_frame(), other->last_frame()) != OverlapNone;

Region::equivalent (boost::shared_ptr<const Region> other) const
	return _start == other->_start &&
		_position == other->_position &&
		_length == other->_length;

what is the status of that option in the session you're working on?
yes, this is poorly/not documented.
for reference, the "start" of a region is the frame offset within its
source file.

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

see above, and i'll await clarification.

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.

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

for "add" yes. for "move", no - that applies to all selected regions.

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

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.

More information about the Ardour-Dev mailing list