On Sunday 09 January 2005 21.47, Stefan Westerfeld wrote: [...] The new EEL, which is pretty much a complete rewrite of what's in the current version of Audiality, is specifically intended to run in the audio thread, acting as the glue between events (such as MIDI I/O) and the RT synth objects. The idea with Audiality is to create a tool that's powerful enough to be used as a "real" synth, while being scalable enough to be useful in games and multimedia for small downloads and/or interactive sound and music. Sort of like a games sound system (like SDL_mixer, HMQ Audio System, FMOD etc) on steroids. Or crack, maybe - I dunno... ;-D I'm also using EEL in a work related control engineering project, that needs to handle hard RT control tasks at 1000+ Hz cycle rates. That's actually the main reason why I decided to go ahead with the VM based rewrite at this point. (You can see in the Audiality TODO that it was planned for much later.) That is, whereas most scripting languages and HLLs are unsuitable for RT tasks, and the few soft RT scripting languages I've found are having trouble with cycle/frame rates above 100 Hz (they're aimed at game scripting), EEL is explicitly designed for that kind of (ab)use. It has about the same hard RT potential as a programming language with manual memory management (like C, Pascal or C++), while providing automatic memory management and some other "real" HLL features. That said, one must realize that instruction decoding, dynamic typing etc causes some serious overhead in any VM, and there's really no way around that, short of implementing a JIT or straight native compiler. Well, almost. There are some tricks. For EEL, I'm planning on automatic type tracking (the compiler detects code paths where variables stick with one type, and selects faster static typed VM instructions, takes memory management shortcuts etc) and of course, *The* performance hack for VMs; taking CISC as far as it can realistically be taken. More and bigger instructions, so you can use fewer of them, and optimize their implementations in the VM better. The biggest performance gain, however, is what is already demonstrated in current versions of Audiality, where a slow direct-from-source scripting engine drives "macro operators" that process entire waveforms at a time. That kind of domain specific "shortcuts" can render the scripting engine overhead practically irrelevant. I'm intending to take that concept pretty far in Audiality - but of course, that's really more of a use case than anything to do with EEL itself. You'll be able to add your own EEL classes with C implementations, so you could implement a generic vector math or DSP package or something if you like. Yes, at least if you want to do traditional explicit sample-by-sample processing directly in the scripting language. JIT or native compiler (compile via C maybe?) might work, but I'll probably focus on higher level operations, such as vector math, running DSP units, processing timestamped events and that kind of stuff. So, as it is, EEL is not an optimizer friendly low level DSP language - but then again, type tracking (effectively turning dynamic/implicit typed code into static typed where possible), compound operators (MACC and the like) and vector operators might help quite a bit... I'm definitely interested in exploring that kind of stuff, but it has to be implemented and tested as well! :-) Well, determinism shouldn't be much of a problem. There is no RT memory manager in this release, but if you're in a hurry, you can probably use the one from RTAI/LXRT, or hack something simple. (Some LIFO pools of blocks of suitable sizes.) Then again, you may not even need it, depending on how your code works! (*) Memory management is done with refcounting + some shortcuts, and as of now, objects are destroyed instantly when they have no references. It should be easy enough to destroy objects "a bunch a cycle" if that fits your application better. Most of the code for that (not much, really) is already in place. The scheduler can easily be wired to destroy some garbage every n instructions, if that's better. (*) Simple values and function "closures" are *not* managed objects! The VM is register based, and uses an array of registers (the heap) as a call stack by moving around a register frame. Basically, "malloc()ed" objects are used only for stuff that doesn't fit in a register, and they're normally passed around by reference rather than being cloned. Bed time... Too much late night hacking lately. //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 ---

On Mon, 2005-10-01 at 10:31 +0000, Steve Harris wrote: 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. I need the guarantee that the audio thread of the language/VM is 100% realtime safe (ala the jack guidelines). Looks like possible choices are EEL, ChucK, and perhaps this "Faust" PaulD mentioned (never heard of it myself). Anyone know of any other alternatives? -DR-

On Tuesday 11 January 2005 00.02, Mario Lang wrote: [...] SC3 looks very interesting, but for me, the GPL license is a showstopper. I need an RT scripting engine for closed source firmware for a lab instrument (small user base of everything but control engineers - the only ones who want our source code is our competitors), and I also prefer my own software (Audiality in particular) to be usable in both Free and non-Free projects. separate thread sounds rather worrying to me... Why, and what does it mean in terms of interpreter/audio engine interactiveness? How "real time" is the actual interpreter? Is the communication sample accurate in terms of when changes are applied to the audio processing graph? I know SC is using incremental garbage collection, but that shouldn't be an issue if it's done right. It can actually be a *better* solution for RT systems than any form of memory management that destroys unused objects instantly. (Let's just say large lists, trees and similar structures are very dangerous in an RT system if you're using some naive form of refcounting or explicit memory management...) //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 ---

Just a FYI/heads up: there is an alternate implementation of jackd (jackdmp, where mp=multiprocessor) being worked on by stephane letz, in which this does not happen. its an experiment at this point, but it can run ardour and several other clients on OSX. --p

On Tue, Jan 11, 2005 at 12:02:31 +0100, Mario Lang wrote: Yep, for performance coding I would say SC is the best bet, I've seen a live coding performance, and it was very impressive. Almost enough to make me want to use emacs. Almost ;) I was thinking of a live C compiler for prototyping and testing purposes. - Steve

On Tue, Jan 11, 2005 at 03:20:40PM +0100, Mario Lang wrote: not sure what you mean by "live", but there is also sfront, which compiles SAOL to C. -- Paul Winkler http://www.slinkp.com

On Tue, 2005-11-01 at 00:51 +0100, David Olofson 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. 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.. I prefer the GPL myself, but as long as EEL is free software (I assume BSD?) it's okay with me. -DR-

On Tue, Jan 11, 2005 at 05:45:05 +0100, David Olofson wrote: ... I understand the motivation for the language, but I do wish you had used an existing syntax, eg. supercollider is based on smalltalk. Having to remember Yet Another Function Declaration Syntax is not on the list of things I want to do. I regualrly have to work in C, PHP, Perl, JavaScript and sometimes Java (often in the same project), and I'm sick of arbitrary syntax choices. My worst example uses Perl to generate PHP, which generates JavaScript (just dont ask, it was easier that way due to missing libraries in different langauges). FWIW, my favourite of these for weakly typed code is JavaScript (aka. ECMAScript). - Steve

On Tue, Jan 11, 2005 at 03:29:24PM +0100, David Olofson wrote: A worthy goal! One little thing I've come to like about Python - you can't use an assignment in an expression like: while x = 1: The rationale, and discussion of some common idioms, is described here: http://python.org/doc/faq/general.html#why-can-t-i-use-an-assignment-in-an-… That whole section also has a lot of rationale for various python features (and some historical warts), so it might be a good read for a budding young language designer even if you hate the choices made ;-) -- Paul Winkler http://www.slinkp.com

ChucK is still in its early stages - version 1.2 is coming out within the month, which allows much greater expressiveness with events, access to shared memory between shreds, events, and many ways to control ChucK from other sources (via OSC, network, etc.), and user objects. version 1.1.x.x demonstrates the primary ChucK concepts of ugen connection, timing, concurrency, and on-the-fly programming. version 1.2 is aimed at making the language usable: http://chuck.cs.princeton.edu/release/soon.html (1.1 can make much noise already, some examples): http://wiki.cs.princeton.edu/index.php/ChucK_Sounds ChucK starts with unit generators, but the primary power of the language lies in the timing mechanism (as Dave noted) and concurrency. Timing can go from sub-sample rate to weeks and months, with sample precision. External real-time events can indeed be polled or waited upon in time loops. What is different about the intents of EEL from that of 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)? 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. I suppose one difference is that EEL is not intended specifically for sound synthesis whereas ChucK is (but certainly not limited to)? (Hmm, how do you make a synthesis language 100% realtime safe?) The ChucK model guarantees data consistency (it will always generate the right samples), and does its best to be on-time. 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. Best, Ge!

On Tue, 2005-11-01 at 01:48 -0500, Ge Wang wrote: I mean RT safe in the jack sense - not calling any blocking functions in the audio thread (ie no allocating memory, locking mutexes, etc.) Sorry, bad terminology on my part. ... Is this why ChucK is always zombie-ing on me? :] -DR-

On Tue, 2005-01-11 at 13:09 -0500, Dave Robillard wrote: There is a feature in Ingo's RT preempt patchset that allows you to do userspace atomicity debugging. I believe recent CVS versions of JACK detect this automatically and build in support for it. With this feature if your JACK client does anything non-RT safe (IOW anything that could schedule()) you get a "scheduling in user-atomic context" message with a stack trace. The first time anyone tried it, using Hydrogen, it immediately revealed a bug where they had used a non RT safe QT call in process(). Lee

On Jan 11, 2005, at 1:09 PM, Dave Robillard wrote: Thank you very much for looking into this. It would be awesome if this fixes the JACK issues we have been having. We are swamped with several projects but we really want to make things right for RtAudio and JACK. (Thanks again to Gary Scavone for RtAudio, which has been great for allowing us to focus on our research). Now that you have tracked down some problems, we would love to take this chance to get our JACK interface working properly. If this is fixed, then it would benefit not only ChucK, but other soundlab projects - sndpeek, rt_lpc, STK, and others that use RtAudio/Jack. Good idea. Let's correspond on chuck-dev || email to go about verifying ChucK/Jack? Best, Ge!

On Tue, Jan 11, 2005 at 10:35:45 +0000, Steve Harris wrote: I should say "coded directly in C", as Faust downcompiles to C IIRC, but its not C that you would write if you had to maintain in in that form :) - Steve

If you're interested in a C/C++ language, you might want to try RTcmix: http://music.columbia.edu/cmc/RTcmix/ It's a real-time music-N style language, been around for a long time. You can compile your app with an RTcmix dynamic library, and then do things like: RTcmix *rrr = new RTcmix(); rrr->cmd("SFLUTE", 7, 0.0, 1.0, 0.1, 106.0, 25.0, 5000.0, 0.5); rrr->cmd("SFLUTE", 7, 1.0, 1.0, 0.1, 95.0, 21.0, 5000.0, 0.5); (etc. -- SFLUTE is Perry Cook's SlideFlute physical model) The language also supports dynamic loading (in r-t, of course!): rrr->cmd("load", 1, "the_code_to_load"); The scheduler can be set up to work with python/perl, or use its own internal C-like syntax to do fun things like (using SFLUTE again): length1 = 50 length2 = 20 for (start = 0; start < 20; start = start +0.2) { SFLUTE(start, 0.7, 0.1, length1, length2, 10000, 0.5) length1 = irand(30, 150) length2 = length2 + 10 if (length2 > 110) length2 = 110 } You can alter/send these scripts at any time during performance. We're about to let go a new release with lots of shiny new features. Runs on most Unix platforms, and a windows version is in the works. JACK/ALSA/etc. supported, as well as multi-channel audio devices for both Linux and OSX. brad