10 Jan
2005
10 Jan
'05
11:24 p.m.
On Tue, 2005-11-01 at 00:51 +0100, David Olofson wrote:
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..
On Monday 10 January 2005 21.31, Dave Robillard wrote:
[...]
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 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.) 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. 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-