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;
> 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 ---
Received on Tue Jan 11 12:15:08 2005
This archive was generated by hypermail 2.1.8 : Tue Jan 11 2005 - 12:15:08 EET