[linux-audio-dev] [semi-OT] EEL 0.1.0 + ChucK

David Olofson david at olofson.net
Tue Jan 11 07:31:27 UTC 2005


On Tuesday 11 January 2005 07.48, Ge Wang wrote:
[...]
> > 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.)
>
> What is different about the intents of EEL from that of ChucK?

Well, EEL itself is "just" a scripting engine, but Audiality (which is 
a synth/sound engine driven by EEL) seems to be rather similar to 
ChucK;

 http://audiality.org/


> If 
> EEL is aiming to do a lot of the things that ChucK already does,
> why not use/embed ChucK with/in audiality (which might be
> beneficial to both)?

That might be an idea. It seems like the two are basically two 
different implementations of the same basic idea.


> Is it licensing?  ChucK is GPL, so that would 
> prevent it from being used in proprietary ways, but it is possible
> for the license to allow special cases to be granted.

Even the LGPL is a bit on the restrictive side for many of the 
potential users of EEL and Audiality, so yes, licensing might be an 
issue...


> I suppose one difference is that EEL is not intended specifically
> for sound synthesis whereas ChucK is (but certainly not limited
> to)?

Yeah, EEL is basically meant as a general purpose scripting language 
for real time applications, such as multimedia, games, music and 
control engineering. Higher level than C, but still without the 
"design errors" that make most languages of this kind more or less 
unusable for RT applications.


> >> 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)
>
> (Hmm, how do you make a synthesis language 100% realtime safe?)

I guess you don't, except maybe if you can figure out a reliable way 
of preventing the programmer and/or user from overloading the CPU. As 
in "Hey, you don't have enough CPU to add that ugen to the current 
graph!"


> The ChucK model guarantees data consistency (it will always
> generate the right samples), and does its best to be on-time.

That's all you can do, realistically... Overloading the system is a 
user error, and there is no correct way of dealing with it. If you 
refuse to perform the operation, you fail. If you obey and the system 
is overloaded, you fail. If you reduce rendering quality to save 
cycles, and the result is unacceptable, you fail.


> The 
> only thing that
> would be needed to make it hard RT capable is to improve mechanisms
> that would know when deadlines are missed (which is quite easy in
> the framework) - otherwise, the language model, with time built-in,
> naturally
> captures many important aspects of RT programming.

Knowing when deadlines are missed may not be sufficient. What are you 
going to do about it, when it happens? You may be able to lessen the 
impact - though of course, that may be sufficient in many cases. It's 
a lot of work to do it well, though...

Anyway, as far as languages go, a language cannot really be inherently 
real time safe. However, it's surprisingly easy to make a language 
totally useless for real time applications, no matter how you use it. 
A "real time environment" is basically one that allows you to solve 
real time problems, if you do things right, so it's basically "just" 
a matter of not building inherently non RT safe mechanisms into the 
language. (GC algorithms optimized for throughput rather than 
determinism would be the most common example.)


Regards,


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list