21 Aug
2004
21 Aug
'04
6:11 p.m.
On Saturday 21 August 2004 05:15 am, Kai Vehmanen wrote:
On Fri, 20 Aug 2004, John Check wrote:
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 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.
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... :)
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.
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
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.
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.
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.
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.