Subject: Re: [ecasound] ecasound 2.0 and beyond
From: Kai Vehmanen (firstname.lastname@example.org)
Date: Thu Apr 05 2001 - 14:11:37 EEST
On Sun, 25 Feb 2001, Kai Vehmanen wrote:
> 01.03.2001 ecasound feature freeze
> xx.03.2001 silent ecasound 2.0 release for packagers a few days ahead of
> the public announcement
> xx.03.2001 ecasound 2.0 release
I guess we can flush this plan down the toilet. ;) I personally blame my
printer for the delay. I've spent numerous evenings trying to get it to
work, but without success. And well, if you even can't get a printer
working, maybe it's not the best time to write code... :)
On the more serious side, most important things to do/resolve before 2.0
are the EIAM sanitizing project and LADSPA licensing. The ALSA 0.9.x API
seems to have finally stabilized, so it's not a problem anymore. The EIAM
changes (most importantly aio-* --> ai-* + ao-*) should be done asap. As
I've mentioned before, 2.0 is more about stabilizing the interfaces than
normal runtime stability.
LADSPA issue is kind of tricky. The file ladspa.h (which defines the
plugin API) only says "The LADSPA plugin API is free to use.". This is
enough for many of us, but it's not the same as explicitly defining the
licensing terms (for instance, using GPL, LGPL, etc). I've already
released ecasound versions that include ladspa.h, so I guess I could do
this again with 2.0. But this will cause problem at least with Debian. So
I'd really like to resolve this. Discussions with the three copyright
holders are continuing... If we just use GPL, it will difficult for
commercial companies to write LADSPA plugins. On the other hand, if we
just release it as public domain, anyone can make uncompatible extensions
to LADSPA or otherwise misuse the API.
-- http://www.eca.cx Audio software for Linux!
-- To unsubscribe send message 'unsubscribe' in the body of the message to <email@example.com>.
This archive was generated by hypermail 2b28 : Thu Apr 05 2001 - 17:53:03 EEST