From linux-audio-dev Sat Aug 21 09:15:49 2004 From: Kai Vehmanen Date: Sat, 21 Aug 2004 09:15:49 +0000 To: linux-audio-dev Subject: Re: [linux-audio-dev] Read this after your first cup of coffee Message-Id: X-MARC-Message: https://marc.info/?l=linux-audio-dev&m=109308338527924 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!