Graham Wakefield

http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm

Lua~ is a Max/MSP external embedding the Lua language along with some 

DSP functions and a scheduler supporting sample-accurate function 

calling using coroutines. A lua~ object embedded in a Max patch can 

load and interpret Lua scripts that receive, transform and produce 

MSP signals and Max messages. Lua~ is particularly well suited to 

granular synthesis, algorithmic microsound and accurate timing needs, 

helpfully circumventing some of the limitations of the Max/MSP 

environment for such work by supporting highly dynamic signal 

processing graphs in parallel processes according to timing 

specifications below block rate. Using an interpreted scripting 

language within a graphical programming environment such as Max 

offers advantages of control flow, generality of data and structure, 

high precision and control, complexity of data and functional 

    -- play a decaying sine to the signal outlet for dur seconds:

    play(Out, dur, Sine(440) * Decay(dur))

    -- launch parallel coroutine, function beep with duration 0-200 ms

    -- wait for up to two seconds    

    wait(math.random() * 2)        

There are a few special advantages to using Lua - its memory 

allocator/garbage collector and general efficiency supports 

interpreting script code in the audio thread, which means that sample- 

accurate function calls and control logic are possible. Lua also 

supports coroutines (collaborative multithreading), kind of like 

deterministic threads that are very cheap to run. I've extended them 

to be aware of sample time, so they can be used like Routines or 

Tasks in SuperCollider 3, but they can embed both control logic AND 

synthesis graphs like SuperCollider 2, and also like shreds in ChucK.

The nicest aspect: you can generate, execute, change and remove any 

number of any types of unit generators to the signal processing with 

sample accuracy, below the block-size, at run-time, within 

The not so nice aspect: Binding Lua to Max/MSP is much less simple 

than binding to Jitter, because of the underlying object model in the 

SDK (Jitter objects have excellent reflection, while only the most 

recently obexed' Max objects do). The main issue is that it is not 

workable to create, connect and modify MSP objects from within a 

script binding. Unfortunately this means that I had to write a new 

set of elementary unit generators rather than re-using MSP object 

code. I'm also in the process of binding the STK library, so a 

standard, familiar set of ugens and so on will be available.

Currently OSX only, but maybe I can get a windows box to compile the 

Lua~ is a Max/MSP external embedding the Lua language along with some  
DSP functions and a scheduler supporting sample-accurate function  
calling using coroutines. A lua~ object embedded in a Max patch can  
load and interpret Lua scripts that receive, transform and produce  
MSP signals and Max messages. Lua~ is particularly well suited to  
granular synthesis, algorithmic microsound and accurate timing needs,  
helpfully circumventing some of the limitations of the Max/MSP  
environment for such work by supporting highly dynamic signal  
processing graphs in parallel processes according to timing  
specifications below block rate. Using an interpreted scripting  
language within a graphical programming environment such as Max  
offers advantages of control flow, generality of data and structure,  
high precision and control, complexity of data and functional  
interdependency and variable scoping.

-- define a function
function beep(dur)
	-- play a decaying sine to the signal outlet for dur seconds:
	play(Out, dur, Sine(440) * Decay(dur))
end

-- repeat forever:
while true do
	-- launch parallel coroutine, function beep with duration 0-200 ms
	go(beep, math.random() * 0.2)

	-- wait for up to two seconds	
	wait(math.random() * 2)		
end

There are a few special advantages to using Lua - its memory  
allocator/garbage collector and general efficiency supports  
interpreting script code in the audio thread, which means that sample- 
accurate function calls and control logic are possible.  Lua also  
supports coroutines (collaborative multithreading), kind of like  
deterministic threads that are very cheap to run.  I've extended them  
to be aware of sample time, so they can be used like Routines or  
Tasks in SuperCollider 3, but they can embed both control logic AND  
synthesis graphs like SuperCollider 2, and also like shreds in ChucK.

The nicest aspect: you can generate, execute, change and remove any  
number of any types of unit generators to the signal processing with  
sample accuracy, below the block-size, at run-time, within  
deterministic parallel execution flows.

The not so nice aspect: Binding Lua to Max/MSP is much less simple  
than binding to Jitter, because of the underlying object model in the  
SDK (Jitter objects have excellent reflection, while only the most  
recently obexed' Max objects do).  The main issue is that it is not  
workable to create, connect and modify MSP objects from within a  
script binding.  Unfortunately this means that I had to write a new  
set of elementary unit generators rather than re-using MSP object  
code.  I'm also in the process of binding the STK library, so a  
standard, familiar set of ugens and so on will be available.

Currently OSX only, but maybe I can get a windows box to compile the  
XP version in the next few weeks.

ann-lua

Sounds awesome Graham, I am really looking forward

to giving the XP version a spin. Please keep us 

Sounds awesome Graham, I am really looking forward
to giving the XP version a spin. Please keep us 
posted.

will try it out as soon as i get some free time.

it seems you are implying dynamic modifications to the signal chain without the familiar msp pop, is this correct?

yeah, it sounds really great.
will try it out as soon as i get some free time.

it seems you are implying dynamic modifications to the signal chain without the familiar msp pop, is this correct?


This is correct - and also independent of block-rate*. For example:

-- changing an FM modulator graph at increasing periods from 1 to 

    carrier:freq(Sine(10, 0) * 500 + 1000)

    carrier:freq(Square(20, 0) * 250 + 1500)

*Though I have to stress the point - because of the current MSP 

architecture, I cannot use existing MSP unit generators inside of 

lua~, so I had to provide new unit generator DSP functions.

On Oct 26, 2007, at 11:08 AM, Robert Ramirez wrote:

> will try it out as soon as i get some free time.

> it seems you are implying dynamic modifications to the signal chain 

> without the familiar msp pop, is this correct?

This is correct - and also independent of block-rate*.  For example:

-- changing an FM modulator graph at increasing periods from 1 to  
10000 samples:

-- duration of one sample in seconds:
local sample = 1/samplerate

-- add a sinewave to the output bus:
local carrier = Out:add(Sine())

for i=1, 100 do
	-- set pulse duration:
	local dur = i * i * sample
	print("duration", dur, "(s)")

	-- create new modulator
	carrier:freq(Sine(10, 0) * 500 + 1000)
	wait(dur)

	-- create new modulator
	carrier:freq(Square(20, 0) * 250 + 1500)
	wait(dur)
end

*Though I have to stress the point - because of the current MSP  
architecture, I cannot use existing MSP unit generators inside of  
lua~, so I had to provide new unit generator DSP functions.

>
> yeah, it sounds really great.
> will try it out as soon as i get some free time.
>
> it seems you are implying dynamic modifications to the signal chain  
> without the familiar msp pop, is this correct?

I download lua~ and tried it. It works very nicely but seems to cost a lot

On 10/26/07 2:52 PM, "Graham Wakefield" wrote:

> This is correct - and also independent of block-rate*. For example:

> -- changing an FM modulator graph at increasing periods from 1 to

> carrier:freq(Square(20, 0) * 250 + 1500)

> *Though I have to stress the point - because of the current MSP

> architecture, I cannot use existing MSP unit generators inside of

> lua~, so I had to provide new unit generator DSP functions.

> On Oct 26, 2007, at 11:08 AM, Robert Ramirez wrote:

>> will try it out as soon as i get some free time.

>> it seems you are implying dynamic modifications to the signal chain

>> without the familiar msp pop, is this correct?

I download lua~ and tried it.  It works very nicely but seems to cost a lot
in cpu for even simple patches.

On 10/26/07 2:52 PM, "Graham Wakefield"  wrote:

> This is correct - and also independent of block-rate*.  For example:
>
> -- changing an FM modulator graph at increasing periods from 1 to
> 10000 samples:
>
> -- duration of one sample in seconds:
> local sample = 1/samplerate
>
> -- add a sinewave to the output bus:
> local carrier = Out:add(Sine())
>
> for i=1, 100 do
> -- set pulse duration:
> local dur = i * i * sample
> print("duration", dur, "(s)")
>
> -- create new modulator
> carrier:freq(Sine(10, 0) * 500 + 1000)
> wait(dur)
>
> -- create new modulator
> carrier:freq(Square(20, 0) * 250 + 1500)
> wait(dur)
> end
>
> Out:remove(carrier)
>
>
> Graham
>
> *Though I have to stress the point - because of the current MSP
> architecture, I cannot use existing MSP unit generators inside of
> lua~, so I had to provide new unit generator DSP functions.
>
>
>
> On Oct 26, 2007, at 11:08 AM, Robert Ramirez wrote:
>
>>
>> yeah, it sounds really great.
>> will try it out as soon as i get some free time.
>>
>> it seems you are implying dynamic modifications to the signal chain
>> without the familiar msp pop, is this correct?
>
> grrr waaa
> www.grahamwakefield.net
>
>
>
>

Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

I had to rewrite lua~ almost from the ground up to get around many 

issues that were causing crashes due to multithreading (and it not 

always being exactly clear what calls are or are not thread-safe in 

the SDK). In the process, a lot of the optimizations I had 

previously had been removed, in order to reduce the number of 

possible causes. This week I'm going to re-introduce them one by 

one, and providing they all work, you should see quite a considerable 

((That said, interpreted control, run-time modification and even 

generation of DSP graphs, with sample-accuracy, is never going to be 

as efficient as a static graph of C externs. But it can get close 

Once the efficiency changes have been implemented, I'll post again to 

On Oct 27, 2007, at 5:56 AM, Gary Lee Nelson wrote:

> I download lua~ and tried it. It works very nicely but seems to 

> On 10/26/07 2:52 PM, "Graham Wakefield" 

>> This is correct - and also independent of block-rate*. For example:

>> -- changing an FM modulator graph at increasing periods from 1 to

>> carrier:freq(Sine(10, 0) * 500 + 1000)

>> carrier:freq(Square(20, 0) * 250 + 1500)

>> *Though I have to stress the point - because of the current MSP

>> architecture, I cannot use existing MSP unit generators inside of

>> lua~, so I had to provide new unit generator DSP functions.

>> On Oct 26, 2007, at 11:08 AM, Robert Ramirez wrote:

>>> will try it out as soon as i get some free time.

I had to rewrite lua~ almost from the ground up to get around many  
issues that were causing crashes due to multithreading (and it not  
always being exactly clear what calls are or are not thread-safe in  
the SDK).  In the process, a lot of the optimizations I had  
previously had been removed, in order to reduce the number of  
possible causes.  This week I'm going to re-introduce them one by  
one, and providing they all work, you should see quite a considerable  
improvement in CPU efficiency.

((That said, interpreted control, run-time modification and even  
generation of DSP graphs, with sample-accuracy, is never going to be  
as efficient as a static graph of C externs.  But it can get close  
enough to be very useful...))

Once the efficiency changes have been implemented, I'll post again to  
let you all know.

> I download lua~ and tried it.  It works very nicely but seems to  
> cost a lot
> in cpu for even simple patches.
>
>
> On 10/26/07 2:52 PM, "Graham Wakefield"   
> wrote:
>
>> This is correct - and also independent of block-rate*.  For example:
>>
>> -- changing an FM modulator graph at increasing periods from 1 to
>> 10000 samples:
>>
>> -- duration of one sample in seconds:
>> local sample = 1/samplerate
>>
>> -- add a sinewave to the output bus:
>> local carrier = Out:add(Sine())
>>
>> for i=1, 100 do
>> -- set pulse duration:
>> local dur = i * i * sample
>> print("duration", dur, "(s)")
>>
>> -- create new modulator
>> carrier:freq(Sine(10, 0) * 500 + 1000)
>> wait(dur)
>>
>> -- create new modulator
>> carrier:freq(Square(20, 0) * 250 + 1500)
>> wait(dur)
>> end
>>
>> Out:remove(carrier)
>>
>>
>> Graham
>>
>> *Though I have to stress the point - because of the current MSP
>> architecture, I cannot use existing MSP unit generators inside of
>> lua~, so I had to provide new unit generator DSP functions.
>>
>>
>>
>> On Oct 26, 2007, at 11:08 AM, Robert Ramirez wrote:
>>
>>>
>>> yeah, it sounds really great.
>>> will try it out as soon as i get some free time.
>>>
>>> it seems you are implying dynamic modifications to the signal chain
>>> without the familiar msp pop, is this correct?
>>
>> grrr waaa
>> www.grahamwakefield.net
>>
>>
>>
>>
>
>
> Cheers
> Gary Lee Nelson
> Oberlin College
> www.timara.oberlin.edu/GaryLeeNelson
>
>

Just updated the lua~ external (still only OSX, sorry). A few minor 

http://www.mat.ucsb.edu/~wakefield/lua~/lua~.htm

On Oct 27, 2007, at 3:23 PM, Graham Wakefield wrote:

>> On 10/26/07 2:52 PM, "Graham Wakefield" 

>>> This is correct - and also independent of block-rate*. For example:

>>> -- changing an FM modulator graph at increasing periods from 1 to

>>> -- duration of one sample in seconds:

>>> carrier:freq(Sine(10, 0) * 500 + 1000)

>>> carrier:freq(Square(20, 0) * 250 + 1500)

>>> *Though I have to stress the point - because of the current MSP

>>> architecture, I cannot use existing MSP unit generators inside of

>>> lua~, so I had to provide new unit generator DSP functions.

>>> On Oct 26, 2007, at 11:08 AM, Robert Ramirez wrote:

>>>> will try it out as soon as i get some free time.

>>>> it seems you are implying dynamic modifications to the signal chain

>>>> without the familiar msp pop, is this correct?

Just updated the lua~ external (still only OSX, sorry).  A few minor  
fixes, and some optimizations.

>>
>>
>> On 10/26/07 2:52 PM, "Graham Wakefield"  
>>  wrote:
>>
>>> This is correct - and also independent of block-rate*.  For example:
>>>
>>> -- changing an FM modulator graph at increasing periods from 1 to
>>> 10000 samples:
>>>
>>> -- duration of one sample in seconds:
>>> local sample = 1/samplerate
>>>
>>> -- add a sinewave to the output bus:
>>> local carrier = Out:add(Sine())
>>>
>>> for i=1, 100 do
>>> -- set pulse duration:
>>> local dur = i * i * sample
>>> print("duration", dur, "(s)")
>>>
>>> -- create new modulator
>>> carrier:freq(Sine(10, 0) * 500 + 1000)
>>> wait(dur)
>>>
>>> -- create new modulator
>>> carrier:freq(Square(20, 0) * 250 + 1500)
>>> wait(dur)
>>> end
>>>
>>> Out:remove(carrier)
>>>
>>>
>>> Graham
>>>
>>> *Though I have to stress the point - because of the current MSP
>>> architecture, I cannot use existing MSP unit generators inside of
>>> lua~, so I had to provide new unit generator DSP functions.
>>>
>>>
>>>
>>> On Oct 26, 2007, at 11:08 AM, Robert Ramirez wrote:
>>>
>>>>
>>>> yeah, it sounds really great.
>>>> will try it out as soon as i get some free time.
>>>>
>>>> it seems you are implying dynamic modifications to the signal chain
>>>> without the familiar msp pop, is this correct?
>>>
>>> grrr waaa
>>> www.grahamwakefield.net
>>>
>>>
>>>
>>>
>>
>>
>> Cheers
>> Gary Lee Nelson
>> Oberlin College
>> www.timara.oberlin.edu/GaryLeeNelson
>>
>>
>
> grrr waaa
> www.grahamwakefield.net
>
>
>
>

Thanx for all you've done with lua~, Graham!

I've downloaded beta 6 and have been playing with it. I get the impression that lua~ is mostly designed for synthesis. So far, however, I've had no luck using it to replace some of the more logic and control functions I'm currently using Javascript for on a project... basically scripting the Jitter (and eventually MSP) processing chains. So some questions, please:

Is it possible to pass variables in and out of lua~? The right output only seems to want to print to the Max window, and the other outs only seem to want the numeric output of ugens. If I could figure how to use Math or other ugen for the control calculations for the variables, I'd still need an I/O method for them (and I have a ton of arrayed vars). Looks like bus and play pretty much just push out numbers with no provision for identifiers. Assuming Math or other method can handle calculations, I thought maybe a worst-case I/O scenario would be to dedicate discrete ins and outs to handling communication of discrete variables... but I can't figure out how to get specific data in/out a specific bus. And if any/all of the above is possible, is it possible with local as well as global variables? If possible, examples of these issues would really help!

Also, is it possible to have global variables shared across multiple instances of lua~ (and Lua scripts)?

Is it possible to embed an actual lua~ script inside a Max runtime for the purpose of hiding it from the public?

> Is it possible to embed an actual lua~ script inside a Max runtime for the purpose of hiding it from the public?

Heaven forbid that the public should actually know

this stuff. Of course, if you're hiding it in a situation

where you're charging "the public" money, did you check

on clearance to use this in something that lines your

Heaven forbid that the public should actually know
this stuff. Of course, if you're hiding it in a situation
where you're charging "the public" money, did you check
on clearance to use this in something that lines your
pockets? :-)


I VERY MUCH appreciate the open, sharing nature of Max and the Max community.

Actually I was thinking more of an installation situation where one does everything they can to secure it from hardware theft and software tampering. If somebody with ill intent should gain access to the system, messing with an exposed script could compromise the entire public experience. Hence my question about "hiding a Lua script from the public". (I'm pretty sure the answer is negative by the very nature of scripts, but thought somebody might prove my perception wrong.)

Anybody have any answers to my other lua~ questions?

I VERY MUCH appreciate the open, sharing nature of Max and the Max community. 

Anybody have any answers to my other lua~ questions? 

Is there any word as to when there will be a windows version of lua~?

Whoops, sorry for the delay, I've been taking (hopefully) the last 

exam in my life and it is a big one. Still not finished actually.

On Aug 31, 2008, at 1:55 PM, Jeff Burger wrote:

> Thanx for all you've done with lua~, Graham!

> I've downloaded beta 6 and have been playing with it. I get the 

> impression that lua~ is mostly designed for synthesis.

Well, I would say computational approaches to the control of 

synthesis, esp. microsound, but yes. That's what I was into when I 

> So far, however, I've had no luck using it to replace some of the 

> more logic and control functions I'm currently using Javascript for 

> on a project... basically scripting the Jitter (and eventually MSP) 

I've had more joy with jit.gl.lua for scripting Jitter, but of course 

I have a little language bias. Unfortunately it's not as 

straightforward to script the MSP chains, as the way the chains are 

built isn't really suited to rapid construction/destruction/ 

reconfigurations, esp. at microtime. That's what lua~ was built for. 

You could think of it as a highly stripped down SC2 in a max object.

> Is it possible to pass variables in and out of lua~?

http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm#call

http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm#outlet

Anything sent out will go to the right-most outlet. In the help 

patch, this is routed to the Max window by default, but you can do 

> If I could figure how to use Math or other ugen for the control 

> calculations for the variables, I'd still need an I/O method for 

> them (and I have a ton of arrayed vars). Looks like bus and play 

> pretty much just push out numbers with no provision for 

> identifiers. Assuming Math or other method can handle calculations, 

> I thought maybe a worst-case I/O scenario would be to dedicate 

> discrete ins and outs to handling communication of discrete 

> variables... but I can't figure out how to get specific data in/out 

> a specific bus. And if any/all of the above is possible, is it 

> possible with local as well as global variables? If possible, 

> examples of these issues would really help!

It's a little hard for me to understand what you're asking. So, lua~ 

deals with two kinds of data, just like MSP. Audio signals are sent 

in to the inlets of the object and are represented in the lua script 

as the In bus. You can access individual channels of the bus as In 

[1], In[2] etc., representing the individual inlets of the lua~ 

object. The outlets are represented as the Out object. Right now 

there's no direct way to write to individual channels of Out, except 

using the Pan ugen, sorry. Anyway, these end up coming out of the 

lua~ object outlets. Connecting up a graph between In and Out is 

what the lua script can do, and it can change it according to 

functions, while loops, coroutines and so on, scheduled in time using 

[ANN] lua~