David O'Toole | 23 Jan 08:46 2007
Face
Picon

problems with ecasound 2.4.5 and ecasound.el


I am using ecasound 2.4.5 and Emacs from CVS (circa a few months ago.)

I would like to build some applications on top of ecasound. I read
about the "SuperEcasound" idea and have decided to try implementing it
in Emacs Lisp and/or Common Lisp. 

To see an audio UI I am building, check out
http://dto.freeshell.org/notebook/ClFrame.html

Anyway, I am having some troubles playing with ecasound.el. For the
most part everything works, however I am getting an error when trying
anything related to channel ops (eci-cop-*)

It says "wrong type argument: stringp, nil" and then seems to keep
repeating that every 2 seconds until I hit Control-G. 

-------------
QuitError during redisplay: (void-function mode-line-mode-name)
Error during redisplay: (void-function mode-line-mode-name)
error in process filter: let: Wrong type argument: stringp, nil
error in process filter: Wrong type argument: stringp, nil
QuitError during redisplay: (void-function mode-line-mode-name)
Error during redisplay: (void-function mode-line-mode-name) [3 times]
-------------

If I do eci-map-cop-list or eci-map-ladspa-list I get the same
thing: the repeating error, and then I hit Control-G. After hitting
C-g I see that ecasound has produced the requested output (the map of
ladspa plugins or whatever.) 
(Continue reading)

David O'Toole | 23 Jan 12:11 2007
Face
Picon

Re: ecasound.el problems. Fixed bug!


I did a little snooping into ecasound.el and it seems I've fixed the
bug all by myself!

The problem was a blank line at the end of the output of eci-map-xxx
functions. 

This prevented me from interactively adding chain ops from
within emacs because it hit an error when trying to build the
plugin-name completion-list. 

But now it works. As you can see below, I just had to modify
eci-process-map-list. 

-------------------------------------------
(defun eci-process-map-list (string)
  "Parse the output of a map-xxx-list ECI command and return an alist.
STRING is the string returned by a map-xxx-list command."
  (delq nil
	(mapcar
	 (lambda (elt)
	   (when (stringp (nth 3 elt))
	     (append
	      (list (nth 1 elt) (nth 0 elt) (nth 2 elt))
	      (let (res (count (string-to-number (nth 3 elt))))
		(setq elt (nthcdr 4 elt))
		(while (> count 0)
		  (setq
		   res
		   (cons
(Continue reading)

David O'Toole | 23 Jan 16:26 2007
Face
Picon

FutureEcaSound: automating my workflow with Lisp


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

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
of ardour: 

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

 2. Paradoxically, I want to do more than Ardour can :-). I want to
    easily mix command-line batch processing tools (like
    "soundmosaic") with automated multitrack processing... I have
    become interested in the dialogue between live improvisation and
    "process music" (i.e. two ends of a spectrum)

 3. Ardour can be very frustrating. Switching to the development
    version (ardour2) helped with the crashes, but its interface is
    very non-scriptable and just doesn't suit my personal taste.

Playing with ecasound's Emacs Lisp interface has made me decide to
develop some Lisp tools for automating my workflow and for creating
new possibilities by integration with other tools (Snd, Common Lisp
Music, soundmosaic, etc)

So my big question is: what are your fantasies for the future of
(Continue reading)

Joel Roth | 24 Jan 00:25 2007
Picon

Re: FutureEcaSound: automating my workflow with Lisp

On Tue, Jan 23, 2007 at 10:26:31AM -0500, 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.

Hi David,

Great to hear about your audio projects and plans.

And somewhat reassuring to know that I'm not the
only one who finds Ardour frustrating at times.

First, I'm amazed at the generality of what you are
planning. Is that typical of the 'lisp mentality'??
(Maybe it's time for me to learn lisp!)

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

> I would like to implement some basic workflow abstractions in Lisp
> that are reduced to basic ecasound primitives like inputs, chains,
> chain ops. Then I will implement basic user interfaces for these
> (possibly using CellMode for Emacs:
> http://dto.freeshell.org/notebook/CellMode.html )
> 
> Some details:
> 
>  - A "session" is a directory with .wav, .ecs, .ewf and a lisp
>    metadata file
(Continue reading)

Kai Vehmanen | 24 Jan 00:56 2007

Re: server connect

Hi Dave,

as usual, a somewhat late reply from me, but hopefully not too late. :)

On Sun, 24 Dec 2006 13:19:06 -0700 Dave Serls <dave <at> dashs.denver.co.us> wrote:

> I'm having problems receiving data from an eca-net-eci server.
>>   Discovered that commands need to be terminated with CRLF from an
>> alternate unixverse.

Yeps, full CRLFs are needed...

>    When running in daemon mode (not a classical daemon) you really need to
>    specify that its interactive mode as well, if you want to issue more than one
>    command.

Hmm, this is indeed somewhat couterintuitive, and probably the behaviour 
should be changed (to -> daemon-mode implies interactive). And yes, 
"enable-socket-interface" might be more accurate description for the 
current daemon mode.

>    While I'm here, the reply to 'engine-status' is '256 11 s' followed by DOS-end-of-line
>    followed by 'not running' and DOS-end-of-line.
>    Is this documented somewhere other than the source?

The documentation is scarce but exists at the end of the Programmer's
Guide:

http://eca.cx/ecasound/Documentation/programmers_guide/ecasound_programmers_guide.txt
http://eca.cx/ecasound/Documentation/programmers_guide/ecasound_programmers_guide.html
(Continue reading)

Kai Vehmanen | 24 Jan 01:02 2007

Re: ecasound.el problems. Fixed bug!

Hi David,

thanks for the patch!

Mario, if you have time, could take a look at this? Should I just commit 
the patch directly to the CVS and bump the version (currently 0.8.3 of 
ecasound.el), or...?

Patch below...

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

>
> I did a little snooping into ecasound.el and it seems I've fixed the
> bug all by myself!
>
> The problem was a blank line at the end of the output of eci-map-xxx
> functions.
>
> This prevented me from interactively adding chain ops from
> within emacs because it hit an error when trying to build the
> plugin-name completion-list.
>
> But now it works. As you can see below, I just had to modify
> eci-process-map-list.
>
> -------------------------------------------
> (defun eci-process-map-list (string)
>  "Parse the output of a map-xxx-list ECI command and return an alist.
> STRING is the string returned by a map-xxx-list command."
(Continue reading)

Kai Vehmanen | 24 Jan 01:46 2007

Re: FutureEcaSound: automating my workflow with Lisp

Hello,

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

  - http://eca.cx/ecasound-list/2004/08/0017.html

My thoughts are pretty much the same still. I've learnt to give up 
(Continue reading)

David O'Toole | 24 Jan 03:07 2007
Face
Picon

EcaSpace!


Hello Gentlemen,

Thanks for your responses. 

I will see what I can come up with, maybe it will interest
people. Whatever it does, it will suit our "working style".
It is to be called EcaSpace. A very preliminary page is at

http://dto.freeshell.org/notebook/EcaSpace.html

A few notes on where the project is going:

I've had to design a unique process for the recording of this
music. As friends and as musicians, we have built up a large library
of recordings that continues to grow. Furthermore each of us has
continued to grow as a musician, both in playing terms and in
ownership of better gear. My purpose is to produce field recordings of
this music, whether a studio composition or improvised live
jamming---for the rest of our lives. 

Obviously I will need an industrial-strength, but still intuitive
process. 

It is already becoming difficult to search and review this catalog of
recordings. So I recently assembled an Emacs-based system for
managing and indexing the collection. There are some notes and
a screenshot toward the bottom of the following URL:

http://dto.freeshell.org/notebook/Linkd.html
(Continue reading)

David O'Toole | 24 Jan 03:10 2007
Face
Picon

Re: FutureEcaSound: automating my workflow with Lisp


Joel Roth <joelz <at> pobox.com> writes:

> First, I'm amazed at the generality of what you are
> planning. Is that typical of the 'lisp mentality'??
> (Maybe it's time for me to learn lisp!)

Yes, the lisp mentality---mega abstraction!

> Perhaps you'll be interested in the templating system I have
> used in generating chain setups.

This is cool. I will definitely steal an idea or two :-)

--

-- 
David O'Toole 
dto <at> gnu.org
http://dto.freeshell.org/notebook/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

(Continue reading)

plutek | 24 Jan 03:46 2007
Picon

Re: FutureEcaSound: automating my workflow with Lisp

On 01/23/2007 09:10:42 PM, David O'Toole wrote:
> 
> Joel Roth <joelz <at> pobox.com> writes:
> 
> > First, I'm amazed at the generality of what you are
> > planning. Is that typical of the 'lisp mentality'??
> > (Maybe it's time for me to learn lisp!)
> 
> Yes, the lisp mentality---mega abstraction!

greetings!

i've been following this thread, and reading your website, david, with  
much interest. the manner of dealing with sound, and all the attendant  
processes, which you describe is exceedingly appealing to me.

i am in the midst of learning scheme, chosen because of my interest in  
working with lilypond, snd, and fluxus. this all leaves me wondering  
whether i might be better spending my time with lisp, the parent  
language.

david, if you wouldn't mind, could you tell me whether you are actually  
working strictly in lisp for most things, or are using some dialect  
like scheme? i'm looking to maximize the general applicability of  
whatever i learn, for various audio- and video-related processes,  
ideally in a realtime context.

as an aside, i'm also quite interested in ChucK, which has an entirely  
different syntax and mindset. perhaps i should be investing my time in  
CLM instead, but it doesn't seem to have the same sort of realtime  
(Continue reading)


Gmane