Re: [LAU] FOSS DAW recommendations

On Fri, Nov 17, 2017 at 08:27:57AM +0100, David Kastrup wrote:

> (....) The problem is that you have various modes with
> fuzzy separation and distribution of tasks, that the mouse does not work
> as usual (regarding context menus on third button etc), that stuff like
> "remove something with the mouse" wanders around and is not discoverable
> with menus or mouse-over help (what was it now? Alt-middle or
> something?). Similar with the keyboard.

Like a physical console, with a GUI like Ardour, you have to
be careful about what you touch with the mouse, and the more
densely packed the GUI the more "twitchy" the interface.
Twitchy also means capable. (Do you remember when MS
introduced menu items that activate, even select actions,
when hovered over? That drove me crazy because it fuzzes
the boundary of what is deliberate choice, with ethical
and political implications: a UI can be used to manipulate.)

One can type on a console by accident, but mousing is more
prone to uncertainties. As David writes, you may not be
using the correct Alt/Shift/Ctrl/Command shift state when
you click. Meanwhile repeated confirmation dialogs are conducive
to mindless trance-clicking syndrome. There is also the
walking on eggshells effect, as with a complicated
spreadsheet, that a touch anywhere can mess things up.
Meanwhile bouncing up and down through menus and back and
forth from windows can lead to some amazingly random
actions.

I'll take the opportunity to tell you that for Nama[1], it was
important to me that the user be able to ask for what she wants
in a concise way, and be sure she gets what she askes for.

There is a lot of room for expressiveness in two or three
text tokens, especially when taken together with a "do" loop
as in shell commands. It is different from what is expressible in
two or three mouse clicks. Mousers end up having to type
anyway, however, mouseclicks can be very helpful in selecting and
interacting, as anyone who has explored inkscape, for
example, or google maps, will agree.

There is no "geometrical overhead" to a text interface. No
question "where was it?" More often "what is it called?"
Which quickly responds to a keyword search. Learning Ardour
involves knowing where something is, because the interface
covers a huge surface.

The main point for me is to have a concise, powerful language,
with every step that effects a project's sound stored under
version control, reviewable, reversible, taggable and branchable.

To simplify working on a Nama project you have a current bus,
current track, current effect, current parameter, current
edit, and you can issue commands for any of those type
without needing to identify the specific object. "vol + 3"
operates on the current track, is easy to type and
unmistakeable when typed at a text prompt that names the
current track. And I think the command is smart enough to
fade up smoothly.

If all you needs are buses and crossfades, effects and
mixing, Nama definitely can do that, tries to help you do
the right thing, includes automatic audio encoding for
mixdown files, mastering network, and other goodies such as
Patrick Shirkeys stereo to 5.1 converter.

Because Nama is a layer over Ecasound, and it is Kai's audio
engine that has provides all the configuration and
processing infrastructure and decades of development and
debugging, so that this developer is free to focus on the
command grammar, generation of the routing graph, fades,
inserts, and realtime control, which is very much cheaper,
altogether a much smaller codebase than a usual DAW. For
troubleshooting, there is the option to inspect the
routing network language of Ecasound config file
(unambiguous to read, quite demanding to write). One can
also inspect the JSON project file or select among numerous
logging options.

That design goes with being able to
know in advance sufficiently about what audio processing
you're going to get when you start the transport rolling.
With a GUI-centric design, you look at the blinkin lights to
know the representation of the audio network. Which is
a great, dense display. I'm pleased to supplement that with
commands that show everything in a few lines of text,
something that you could even print and review on paper.

Another idea is to avoid the risk of breaking something at
any stage in a project. That, after all, is what
"non-destructive" editing implies. Even a track that has
been "frozen" in Nama can be restored to its live state
(with the frozen state still selectable) without
disrupting the rest of the project.

Having reusable components, such as applying changes over
multiple tracks, or creating chains of effects and profiles
with effect chains associated with track names is another
way to avoid breakage caused by mistakes when one tries to
repeat a particular setup action.

If it's MIDI, probably you can get much more from the other DAWs,
unless you are a do-it-yourselfer. For mixing a few hours
a year, Nama does make Easy Things Easy(tm), IMO.

> It is very prone to crashes and hangs when anything with the transport
> goes wrong, and it's not exactly trivial to restart transport.

I think the Ecasound transport is more forgiving, and easily
rebooted.

> Its autosave does not just leave a recoverable state but actually saves the
> whole thing periodically as the current project, so if you don't know
> whether you actually want to commit (or are pretty sure you don't) you
> have to turn it off, or quitting without saving will leave you in some
> unpredictable state.

It can be easier: with Nama, the user can tag the commits
she likes and can later load any tag.
 
> I recently had a demonstration where the mics were wired wrong and so
> the two "stereo" channels I recorded on were mixed up. You think I
> managed to split the tracks into mono in order to salvage two usable
> tracks? No beef. I'd have had to do a stem export and reimport. Or
> something. Didn't really fit in the demo time frame.

You can have a DAW and still use a swiss army knife for
special processing.
 
> Handling marks (setting, moving them) is always hit and miss.
> Manipulating automation with the mouse is hit and miss. And so on.

It is hard. Maybe it can become easier.
 
> Ardour is fine for making takes.
 
> It's when you start editing that things get awful.

Well, depending on the type of editing, some of those are things
may be things that other DAWs are unable to do.

In Nama, the work with regions is relatively trouble free.

cheers,

Joel
 

1. Install from https://metacpan.org/release/Audio-Nama
   (slightly dated) web page: https://freeshell.de/~bolangi/cgi1/nama.cgi/00home.html

> --
> David Kastrup

-- 
Joel Roth
  
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
https://lists.linuxaudio.org/listinfo/linux-audio-user