Dave Robillard <drobilla(a)connect.carleton.ca> writes:
On Tue, 2005-11-01 at 00:02 +0100, Mario Lang wrote:
Dave Robillard
<drobilla(a)connect.carleton.ca> writes:
On Mon, 2005-10-01 at 10:31 +0000, Steve Harris
wrote:
On Sun, Jan 09, 2005 at 09:47:12 +0100, Stefan
Westerfeld wrote:
> Hi!
>
> On Sun, Jan 09, 2005 at 09:08:22PM +0100, David Olofson wrote:
> > There! I've decided the new, rewritten EEL scripting engine is about
> > ready to start playing around with.
>
> My BEAST Evaluator plugin allows the user to add custom DSP code like
> writing
>
> output = sin (input_1 * 7) + 1 + 0.4 * last_input_1;
> last_input_1 = input_1;
>
> in a property at the GUI, to allow the user to add its own custom DSP
> code. But its really just started, thus I am wondering whether EEL is
> intended for this domain (RT audio processing), or whether it will be
> too slow. Then I might rather work on an BEAST EEL module.
Ooh, interesting, I've been wanting to write a DSSI plugin like this for
some time. I was going to use compiled C though :)
- Steve
I'm very interested in the idea of being able to code modules in a
modular synth live (in realtime) as well.
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.
Have you looked at SuperCollider3? It is designed for RT, allows for live
coding in all sorts of ways (JITLib) and can easily be controlled from
other apps (the client and server side both can send and receive OSC) and
it has 8 JACK in and out ports by default.
I would rather not have to do things through jack ports, and actually
take the language's VM (or whatever) into the synths' engine. Mostly
because adding and removing jack ports causes clicks, and that's not
acceptable.
I forgot about supercollider, it's a possibility assuming it can
add/remove code on the fly.. I think that's what that JITlib may do?
Not quite, SC can by default add code on the fly, JITlib is
just yet another convinience layer for live coding.
For instance, if you have your server running and some sound
playing, the following line of code, if executed, adds yet another
running synth to the server:
SynthDef(\test, {|freq|
Out.ar(0, SinOsc.ar(freq, 0, 0.1))
}).play(s, [\freq, 440]);
THat is default behaviour, so you need no extensions
for such functionality. JITLib is even yet a step further.
The popularity of SC is a plus at least.
I love it beyond description. Its the collest thing in LA
world since many years, me thinks (OK, except for JACK).
--
CYa,
Mario