Subject: Re: [ecasound] SuperEcasound (was: Re: Music-specific features)
From: S. Massy (smassy_AT_sympatico.ca)
Date: Tue Aug 26 2003 - 22:53:24 EEST
On Tue, 26 Aug 2003, Kai Vehmanen <k_AT_eca.cx> wrote:
> I feel that this and many other similar features should be implemented
> conceptually at a higher level... SuperEcasound!
> At this point there is very little room to expand Ecasound's scope of
> functionality. Primary reason for this is that I simply cannot handle more
> code with the time I currently have for Ecasound development. This
> scalability problem manifests itself in many ways:
> a) amount of source code to maintain; currently over 60,000 lines of
> code plus non-insignificant amount of documentation
> b) compile and link times; on my fastest machine it takes over half an
> hour to compile Ecasound; this means it's pretty impossible to
> work ~0.5h every day with Ecasound, I have to find time for
> a whole evening
> c) features; introducing the testsuites has helped, but we're
> still years away from having a complete testsuite that could
> help to maintain the current huge feature-set
Would it help to bring ecasound to a greater level of modularity? I
admit I haven't really looked at ecasound's source code in the last year
but, back then, it used to be pretty hairy and scary for the
non-initiated. I believe a plugin interface of sorts existed for rt
objects drivers but that was about it. Perhaps separating everything
cleanly: engine, effects (with each effect in its own subdir), and so
forth, would help maintainability, speed up recompilation and help
tentative developpers to find their way up and down the source tree more
easily? Just a thought...
> ... so it's is highly unlikely (although not impossible) that I would add
> major new areas of functionality to the core Ecasound package.
> But, but, the situation is not as bad as it seems. It should be quite
> straightforward to create a new frontend - SuperEcasound! - that would
> extend Ecasound's functionality. Writing a simple custom frontend for the
> interactive mode is pretty straightforward using the ECI interface. One
> of the great benefits is that SuperEcasound can be written in C, Python,
> Perl, PHP, elisp or some other ECI-supported language.
> Now this is not exactly a new idea. Some of the existing projects like
> ecasetupedit and ecasound.el have taken a SuperEcasound-style approach.
> But so far nobody has worked on a project that aims to extend the current
> interactive mode (i.e. evolutionary approach), imitating its look and feel
> so existing users could easily migrate from "ecasound -c" to
Yes, and this has been wanting for a long time.
> There are quite a few ideas that could be added to the new interface
> - support for custom timeformats (hh:mm:ss, SMPTE, etc)
> - scheduling of ECI commands (timestamping/sequencing)
> - position markers (search the list archive for posts written by
> Julien Claassen and Jeremy Hall concerning this feature)
Or just plain variables to hold values and a special type for markers.
> - command aliases
> - command macros
examples: copy, cut, paste, export region to file, etc.
> - user-interface capable of realtime feedback
- A special mechanism to help managing parameters of complex LADSPA
> - etc, etc, etc
> Now personally I'm going to continue concentrating on maintaining and
> improving the Ecasound core, so I won't have time to start SuperEcasound
> development. But I sure welcome anyone to start work on the project!
> Audio software for Linux!
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Tue Aug 26 2003 - 22:57:21 EEST