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@xxxxxxxxxxxxxxxxxxxx https://lists.linuxaudio.org/listinfo/linux-audio-user
