[Ardour-Dev] Set Selected Regions

[Paul Davis]

On Wed, 2007-10-03 at 13:43 +0100, Tim Orford wrote:

> 
> The point is that blindly going through a list is inferior to
> having an overview of the list before making changes.

well, that depends on whether the list is a list of commands or a list
of states. if you are using an editor where there is a list of commands
like "normalize" and you can selectively disable that command (GIMP
works like this), then yes, i agree that a list is useful.

but when the list is a list of states, i don't agree that its really
very helpful at all.


> Its sad to hear that the users have worn you down :-)
> It might be worth bearing in mind though, that 1) the people
> on your forums might not be your long-term target users, 

true, but i've seen similar comments about cubase's branched history
feature (introduced 2-3 years ago). i think their end user community is
pretty well defined at this point.

> and 
> 2) that it might be the implementation rather than the idea
> that is lacking. 

i agree. i certainly would never claim that anything in ardour has been
done perfectly.

> Support is obviously an important resource
> concern of course, but I'm sure you dont fully subscribe to
> the idea that good software design is just about 
> satisfying the casual user.

i didn't mean "casual users". i meant users for whom concepts like
trees, branching structures, lists and so forth are not second nature. i
know plenty of musicians who really do not think like this at all.

> I do feel strongly that Undo is a critical feature for
> any creative production tool once the basic featureset is complete.
> Advanced 'versioning' of a project needs to be incorporated into 
> the tool to avoid hitting the brick wall you often get after using 
> a tool for a year or 2.

ardour tries to focus on snapshots for that. the way they work at
present is not optimal by far, and its not even feature complete, but i
believe its closer to the workflow that users actually want than a
branching history list.

> I did try some UI coding, but it appears that the Ardour model
> classes dont support iterating over the history list and I got 
> discouraged at that point. 

they support set_state(const XMLNode&) and XMLNode& get_state() const.
they do no store history state themselves. playlists once did this and
it was a design nightmare. 

> I quite beleive you when you say this
> area is a 'nightmare', but did you find the nightmare to be with 
> the model or the UI?

usability and internal design in the model.

now the mea culpa moment. one of the primary defects in libardour's
models is that they were originally implemented with a negative view
toward making their state always serialiazable/unserializable. this was
a very serious design error on my part, and although from a strict
technical perspective its mostly been rectified, the echoes of the
mistake live on in all kinds of subtle ways.

that said, ardour's undo/redo history will be moving away from universal
use of object states towards partial use of stored commands. this is
particularly critical for playlists, where currently any operation on
the playlist ends up storing the entire playlist state - incredibly
wasteful. brian ahr and myself have got a nice command object working
that will allow us to just store an object ID, a named method and its
arguments in the undo list.

this doesn't address the issues of idempotency that i raised in my
previous email, but it will dramatically cut down on the amount of data
involved in storing undo history, and also the runtime cost of restoring
"state" when undoing/redoing for certain kinds of commands.

--p