Re: [linux-audio-dev] [semi-OT] EEL 0.1.0

From: Dave Robillard <drobilla@email-addr-hidden>
Date: Tue Jan 11 2005 - 05:22:18 EET

On Tue, 2005-11-01 at 00:51 +0100, David Olofson wrote:
> On Monday 10 January 2005 21.31, Dave Robillard wrote:
> [...]
> > I was considering using ChucK, given that it's specifically
> > designed for RT performance use and can insert/remove/replace
> > pieces of code into the vm while running, but it looks like it
> > would be a significant amount of work to adapt the ChucK engine to
> > be controlled by another app.
>
> Looks like ChucK is basically designed around the idea of describing
> networks of unit generators, though there does seem to be procedural
> style flow control constructs. Maybe those can be use to construct an
> event loop for receiving external real time events? It would seem to
> fit well with the "time loop" idea, but I don't know how dynamic the
> control flow can be without causing all optimization to break down.
>
> Anyway, I'll have a closer look at ChucK. It has some concepts in
> common with what I had in mind for future versions of Audiality.
> (Running those AGW scripts in real time, all unit generators in
> parallel, rather than over whole waveform as it is done now. Time
> oriented flow control constructs.)

Yes, the basic sound production in ChucK is based on ugen networks, but
the cool thing about the language is it's handling of time. Time is
essentially a variable, so you can do a bunch of operations, then
increment time (ie "now += 1 second") and do some more operations. It's
really great for algorithmic composition and things like that.

It's main attraction to me however is the ability to
insert/delete/modify chunks of code on the fly, while everything runs.
That would be ideal in a modular synth - those "chunks of code" are just
modules. The only problem is a chunk of ChucK code doesn't really have
a way to specify inputs and outputs that I know of, so the language
and/or vm would have to be modified a bit to allow coding of modules
with arbitrary inputs and outputs.

> > I need the guarantee that the audio thread of the language/VM is
> > 100% realtime safe (ala the jack guidelines).
>
> That's a primary design goal for EEL (which is the main difference
> from scripting languages in general) - but raw speed is another
> matter. Of course, I'll try to make EEL as fast as realistically
> possible, but as long as it isn't compiling into native code,
> instructions will be expensive, and doing DSP by actually operating
> on a single value per instruction (as opposed to SIMD) is going to be
> very slow, compared to native code.

Fast as realistically possible is fast enough for me. :) If performance
of a patch with code in it needs improving, one can always go write the
LADSPA plugin. At least having a scripting language available means you
don't /have/ to write a LADSPA plugin to get something done.

The fact that a primary design goal is RT safeness is very appealing,
I'll take a good look at EEL as it stands..

> Another problem (for me at least) is that the few alternatives that
> looked interesting are either non-Free, or licensed in a way that
> prevents using them in proprietary projects - which is exactly what I
> need to do. (All my personal projects are Free/Open Source, though.)

I prefer the GPL myself, but as long as EEL is free software (I assume
BSD?) it's okay with me.

-DR-
Received on Tue Jan 11 08:15:04 2005

This archive was generated by hypermail 2.1.8 : Tue Jan 11 2005 - 08:15:04 EET