David McClain ignited some interest on the LispWorks mailing list when he celebrated some major performance gains for his Lisp audio application. After getting several requests for more information, he followed up with some details:

He also sent me this message, with some screenshots:

Hi Zach,

I don't have a white paper on this, per se, but it is being heavily used in our GigaDSP simulator (see attached pics), which is (except for the vDSP FFT library use), a 100% Lisp program. GDSP uses a form of reactive programming (RPS) to effect a totally asynchronous network environment. Blocks with brown lower borders are system primitives, coded in Lisp with super-macros that describe everything from how they respond to inputs on their pins, to how they respond with editable properties, and save persistent properties.

But complete asynchrony means total anarchy too, so you can't predict when one block will fire over another. To fend off this non- determinism, where needed, we use a sub-clocking device that issues sub-cycle clocks in a predictable order, all of which must fire and complete before the next major clock cycle. That way we can use an asynchronous network to effect a systolic chain of processing.

The pic with the beige background is the top-level network environment. If you double click on a macro block (those with blue lower borders) you open up their editor (the blue background) which is just another nested network. This can go on to arbitrary depth. So in addition to coding high-performance primitives in the Lisp super- macros, any (unknowledgeable about Lisp) user can design his/her own processing blocks out of combinations of other primitive and macro blocks.

There are property sheets and block selection menus that can be popped up on the display. I also use this to model audio processors ( refined-audiometrics.com ). GDSP allows me to visualize the transients that go by so quickly you wouldn't be able to catch them otherwise. Then after exploring the math and the algorithms in GDSP, I take the results and implement them on a 20-DSP Kyma system (www.symbolicsound.com) for realtime performance and analysis on real audio being piped through my studio here in the lab. Kyma is a Smalltalk environment, and Capybara is the 20-DSP realtime audio processing box that Kyma (the language) controls.

All in all, the whole setup here from Lisp and GDSP through Kyma and Capybara is hard to beat. The only thing that would make things even more fun would be to have all of Kyma written in Lisp too!

We use GDSP to help us design ultra-high-speed wireless radio links (10-40 Gbps) operating in the millimeter wavelength regime (100-200 GHz). See our company promo at www.asyrmatos.com

Let me know if I can answer any other questions for you.

Cheers,