Steve, At the moment it is very elementary and probably easily reproduced. It's also the first check I could come up with and it was good enough to help me identify my issues. As this tool/concept gets exposed to the real world and used in different applications, scenarios, etc it would be /very/ convenient to have the full power of ecasound and the LADSPA plugin architecture available at our disposal from FS. There are plenty of people out there (hint, hint) that know far more about audio processing, etc than I do. I'm sure they could come up with some very, very cool applications once FS audio can be put through ecasound/LADSPA (think mod_soundtouch on steroids). I don't want my lack of understanding and foresight to get in their way. Ecasound looks like the right tool for job and I'd hate to let something small like "licensing" get in the way ;) I've already e-mailed the creator for an LGPL exception but the message bounced. I'm looking for other addresses and contacts. Hmmm... Maybe we could skip ecasound and just implement a LADSPA host in FS (LADSPA is LGPL). My only concern here is the ability to write LADSPA plugins. The barrier to entry and learning curve is certainly higher than some basic ecasound params. On Fri, Feb 13, 2009 at 6:56 AM, Steve Underwood <steveu@coppice.org> wrote:
Hi Kristian,
What you are doing now looks very elementary, and there is no real reason to use ecasound. I don't know what you intend to do as you flesh out this quality assessment, but its not clear to me where ecasound would ever be a big benefit in such a tool.
Not using ecasound certainly simplifies its licencing issues. :-)
Regards, Steve
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com