Re: [ecasound] FutureEcaSound: automating my workflow with Lisp

From: Kai Vehmanen <kvehmanen@email-addr-hidden>
Date: Wed Jan 24 2007 - 02:46:56 EET


On Tue, 23 Jan 2007, David O'Toole wrote:

> I am getting into ecasound, and I would like to start up the old
> "SuperEcasound" discussion that happened on the list wayyyy back.

thanks for starting up the discussion again!

> I have used Ardour a lot the last year or so, and have built up many
> hours of sessions. However I'm realizing a few things about my usage

Now that's a first -- I think you are the first one here, moving to
Ecasound from the Ardour camp! :) Oh well, that's probably a very positive
indicator that Ardour has become a relatively mature project.

> 1. I hardly use anything beyond the very basics of ardour's
> feature-set. Our band's style is about capturing the music as it
> happens, and throwing away whole takes if it doesn't work. I have
> no use for punch-in/punch out, really complex automations, or
> sequencing of loops (i.e. Ableton Live type stuff.)

That's exactly the mode of working I'm most confortable with, and also the
approach that has been the guiding use-case in ecasound development!

I wrote a rant back in 2004 which touches this topic (and various others):


My thoughts are pretty much the same still. I've learnt to give up
expanding ecasound functionality to areas, which are already covered by
others. Most people will continue to record with arecord, apply simple
effects with sox, and use Ardour for their mt-recording tasks -- and I've
learnt not to push ecasound for all possible uses, but instead accept that
the other tools are good as well. ;) But for certain use-cases, which
share similar motivations as I've described my rant above, ecasound can
provide a good tool.

> So my big question is: what are your fantasies for the future of
> Ecasound and SuperEcasound? What kind of things would you like to see
> in a lisp-based/emacs-based ecasound application?

Joel already had a good point about everybody writing their own frontend.
And I guess there's a lot of truth to it. It would seem many people use
ecasound, and the assorted other console audio tools, in much the same way
as people use for instance Pd. They build custom environments for playing
live, and/or composing tracks .. and the environment might change from
track to track. The environment/setups are shared, and they are often
useful to others, but more as starting points, rather than complete

On the other hand, as I've come to note that other people have found
useful the approach to recording and mixing taken by ecasound, I think the
same could have to a higher layer interface (SuperEcasound, or something
totally different).

But designing this will be somewhat difficult, as Ardour/Protools type of
interfaces (and on the other hand Pd/CSound/etc) dominate how people think
about "creative" audio software.

A safe starting point would be to manage the work-flow in a
useful/innovative way. Ecasound provides only minimal support for work
flow management -- the user has to mentally switch between 'recording',
'adding processing', 'mixdown', 'session playback', etc modes of
operation, and for instance decide how the files are managed in each of
the modes. And higher level interface could hide these details (and many
of the frontends have done exactly this, but of course often in slightly
different ways).

> - A "clip" is a section of a take (i.e. defined by ewf)

Btw, the "ewf" files are still quite limited, and ecasound will have
problems if you start to have lots of small files you want to sequence.
On the bright side, there's a lot of room for improvement without
modifying the current engine architecture, but someone has to do the
design and implementation work (ewf-v2 has been in planning for quite
some time).

> my hardware setup:

Wow, that's nice!

  links, my public keys, etc at
Take Surveys. Earn Cash. Influence the Future of IT
Join's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
Ecasound-list mailing list
Received on Wed Jan 24 04:15:04 2007

This archive was generated by hypermail 2.1.8 : Wed Jan 24 2007 - 04:15:04 EET