[Ardour-Dev] Ardour 2.3 released

[Fons Adriaensen]

On Mon, Feb 11, 2008 at 08:54:02AM -0500, Jesse Chappell wrote:

> On Feb 11, 2008 7:48 AM, Fons Adriaensen <fons at kokkinizita.net> wrote:
> 
> > For doing simple, manual but very precise edits in an
> > efficient way Ardour is still not what it could be.
> > I'd much love to see that improved rather than new
> > features being added.
> 
> If you could elaborate on some of your ideas here, there's a good
> chance someone (other than you, even) might step up and do it!  Good
> GUIs are hard, and we need all the help we can get.

I know it's hard !
 
> In terms of features getting in your way, don't hesitate to
> specifically cite them.  Menu bloat is one thing that could be dealt
> with by some added user configuration that lets you pick and choose
> the set of items that might show up.  Other than that, tell us what
> your issues are with the main editing canvas / other workflow stuff.

W.r.t. to precise editing:

* Generally it's a bit too easy to move things accidentally.
  There's undo of course but you quickly get tired of this.
  If you lock a region it can't be moved at all. Using some
  modifier key to enable moving a region would help. 
  
* There are two ways to have fine control on the time scale:
  - The first one is too zoom in up to a magnification
    where the screen resolution is no longer the limiting
    factor. But then you quickly get lost since you don't
    have a larger scale view. It's just not practical to
    work at a zoom level that provides enough resolution.
  - the 'nudge' keys. Currently the smallest step is 10ms,
    and that's too much. Also it's a pain to change the 
    step size, and the hh:mm:ss:dd format isn't really
    what you need here. There are several solutions for
    this that would not take up more screen space than
    the current controls.

* Some way to 'scrub the tape' would be very practical
  to locate the point you want to edit. All it needs is
  a small textured strip somewhere that you move with
  the mouse, and having a variable scale factor.

* Some way to quickly test an edit (i.e. hear it in
  context) without having to scroll the screen, move
  the edit cursor, etc. Single button, with configurable
  pre- and post times. Variations on this are to hear
  only the first half, or the second (i.e. the fade-out
  or fade-in). 

* Easier control over the shape and length of the cross-
  fade.

* A difficult one: a practical way to handle level changes
  over an edit.


In the 'small pains' department: the varispeed wheel.
Try to get exactly 50% - not possible, you can have
49 or 55. Same with the semitone scale: 11 or 13 but
not 12. The control law (more resolution around zero)
is well chosen, but the effect of its quantisation to
integer (pixel) inputs was apparently never considered.

Going to the 'attention to detail' level, arbitrary
quantisation of control values is a general problem.
Sometimes you want to set up *exactly* -20dB gain for
example. On a 'professional' tool it should be possible
to do this (but maybe I'm missing the trick).

> Also, the whole surround stuff that got an embyronic start last summer
> still hasn't shown up.  I know you probably just use Ardour as a
> vessel for raw B-format, but if there were good interfaces for panning
> support (simultaneous and independent stereo and surround panning per
> track) even you might be tempted to use those kind of features.

Actually I'm doing multitrack panned AMB mixdowns, but it's
not very practical with each panner being a separate window...
(also the first thing that disappears from the plugin title
window when it's too small is the track's name...)

> And
> if you wouldn't, think about what would it take for you to do so.
> Obviously this is a separate discussion, which will happen whenever
> someone steps up to finish what was started.

The issue turned up recently on the surround sound list
where I do my occasional bit of Ardour promotion and Joern
does a lot more. As a result I got a mail from Christian
Muise telling me that the code is actually in some branch,
and that the blocking factor to get it merged was the
difficulty of integrating the panner into the GUI.

I repeat my offer which I have made before: if someone
would take up the GUI side of things (/me not being a
GTK guru) I'd be happy to take care of the DSP part.

-- 
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.