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

[John Check]

On Saturday 21 August 2004 05:15 am, Kai Vehmanen wrote:
> 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'll assume mini != "porta", although some of them have enough I/O to make a 
challenge. I don't know you and that was my perception. Whether it was 
accurate of not, all I could base it on was your app.
You obviously had to have had knowledge of what jobs it needed to get done
in order to code it. 

> 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.
>

I don't recall seeing a distro that didn't have vendor packages, so it's 
definitely viable, just not for everybody.

> 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).

BTW, I didn't say it, but I think that kind of flexibility is a good thing. 
A traditional front end as an option would moot my point. 
That's not a request, just an observation.

>
> 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

Yes, but you know it intimately so you have an edge.

> 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.
>

A well taken point. IIRC when I first looked at ecasound the other option was
SLab, which performance aside may have gone a little too far in the opposite 
direction WRT representing the analog paradigm.

> 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.
>

Provided one is comfortable with text and familiar with the terminology in the 
doco.

> 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.
>

I have to check what's in the package as far as examples goes.

> 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

It's an oversimplification. Somebody that dropped $$ would have perused the 
manual while they were setting it up, and probably got a demo at the store, 
or saw it in action. Nothing in a studio is intuitive except the chairs, so 
yes, the analogy does require a threshold of knowledge, but you'll have to 
agree that the knowledge doesn't transfer directly.

> 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.
>

Yes, well, one time at a gig, the drummer locked his keys in the car. It took 
him all night to get me out ;) 

They do know what a tape transport looks like and you have to press record.

> ...
>
> Now as for rest of your argument, I don't really disagree with it.

Which is good.

> 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.

It was the first capture and processing app that came to mind. Remember, I 
didn't say it was useless.

>
> 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.

That's consistent with why I used it as an example. It just needs to be 
prechewed to fit into a turnkey system, like everything else.