[linux-audio-dev] Read this after your first cup of coffee

[Kai Vehmanen]

On Fri, 20 Aug 2004, John Check wrote:

> I specifically said Cecilia because it's a GUI. IIRC correctly, the 
> ecasound originator coded it up because he found the interface to GUI 
> systems to be dense, which doesn't give me confidence he'd have been 
> able to find his way around an analog studio.

Now this I have to commment on. :) I'm the orinagor in question, and I 
actually do have an analog mini-studio (and had one before I started 
coding Ecasound) and very much like to use this gear.

I don't like to use the DAW-GUIs, because to me they are cumbersome and 
slow to use when performing simple recording tasks (=those tasks that you 
do also on analog multitrackers). And this is why Ecasound has been 
developed to be what it is today.

Of course nowadays people perform much more complex tasks when recording
and especially when editing. For these, the Ardour/Protools style apps are 
better suited, no question about it.

I also admit that I'm not a "visual person" in the sense, that I in 
many cases prefer textual descriptions over diagrams and drawings. This 
applies to sw architecture as well as to studio signaling -- and I guess 
to audio app UIs... :)

> The main feature of ecasound on which I base my opinion is it's signal path 
> from scratch nature. Basically, it's a virtual kit and you have to put 
> together what you want. 

This is true, but at the same time ecasound allows you to restore or reuse 
signalling paths from old projects very very easily (just copy&paste or
reuse old scripts).

When I start a new project, I just copy the relevant script from the 
previous project, edit the filenames and do other minor changes, and 
start recording. That takes less than 15sec usually. :) And as I can 
express the whole "state of the studio" with a few lines of ecasond 
options, I can with a quick glance verify to myself that everything is 
in order. With complex GUIs, there are so many windows, menus and views 
that it takes time to verify all settings.

Hmm, to me ecasound is much like the good old 'find' command. Its syntax
seems cryptic (even for relatively simple searches), but when you finally
decide to learn how to use it and play around with the different options
for 15min-1h, you suddenly find yourself at home with the tool and you
feel comfortable building even complex searches.

Also much like ecasound, when you create a complex (but useful) find 
search, you can copy it to a text file or a script, and later on use it as 
a starting point for new (but similar) complex searches.

And also, regular mortals do use find. It's not the first thing UNIX 
newbies start using, but still, it is used by a lot of (otherwise 
normal :)) people. I think same applies to ecasound.

> That's extremely useful, but if an average musician 
> never used ecasound before and awoke at 2am with a great melody, (?|s)he'd 
> never get it tracked because ecasound is too different from the traditional 
> interface paradigm.

Now that's not really a good example. No matter what the tool is (analog 
4-track, protools, ecasound) you have learn how to use it. I doubt average 
musician could do much with protools either. Quite a few couldn't operate 
an analog multitracker.

...

Now as for rest of your argument, I don't really disagree with it. 
Although Ecasound is designed for actual real-life use, it is still a 
"niche product" as:

  o the user-interface concept is unique to ecasound -> people cannot
    reuse their experience from other apps
  o Ecasound's primary target platform is Linux which itself is 
    still a "niche product" in the desktop-PC market
  o Ecasound does not offer a complete DAW feature-set

... and because of these, it will continue to be a niche product for 
the foreseeable future. And that's perfectly ok to me. :)

And I don't think it's fair to use Ecasound as an example of state of
Linux audio. Even I (!) rather use Ardour, Rosegarden, JAM et al when 
demoing to an audience I know are familiar with Mac/Win audio apps.

To continue with my UNIX comparisons, that's like showing gdb, emacs and
vi as the only options to an audience of .NET/Java developers, when you
should be showing DDD, KDevelop and Eclipse as well.

-- 
 http://www.eca.cx
 Audio software for Linux!