Subject: Re: [linux-audio-dev] Read this after your first cup of coffee
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Sat Aug 21 2004 - 12:15:49 EEST
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!
This archive was generated by hypermail 2b28 : Sat Aug 21 2004 - 12:19:34 EEST