020200

I was wondering why JavaScript - which coding is a pain - got such prominent place in maxMSP, while Lua doesn't?

I think Lua is the perfect solution for scripting, doing logic or mindles repetitive task, so thinking about Lua intergration instead of JavaScript would be neat.

Lua is mostly used for scripting of games (to give Funcionality and Logic into Gamemaps und such). I even made a pixeledtor in Lua for the PSP: 

http://www.node3000.com/digital-tools/download/smoove_pixel_tile_and_spriteeditor_for_sony_psp_psplua.php

Lua is mostly used for scripting of games (to give Funcionality and Logic into Gamemaps und such). I even made a pixeledtor in Lua for the PSP: http://www.node3000.com/digital-tools/download/smoove_pixel_tile_and_spriteeditor_for_sony_psp_psplua.php

lua-intergration-into-next-maxmsp-version

> I was wondering why JavaScript - which coding is a pain - got such prominent place in maxMSP, while Lua doesn't?

> I think Lua is the perfect solution for scripting, doing logic or mindles repetitive task, so thinking about Lua intergration instead of JavaScript would be neat.

> Lua is mostly used for scripting of games (to give Funcionality and Logic into Gamemaps und such). I even made a pixeledtor in Lua for the PSP: 

On 5/31/07, Martin Wisniowski  wrote:
>
> Hi all.
>
> I was wondering why JavaScript - which coding is a pain - got such prominent place in maxMSP, while Lua doesn't?
>
> I think Lua is the perfect solution for scripting, doing logic or mindles repetitive task, so thinking about Lua intergration instead of JavaScript would be neat.
>
> Lua is mostly used for scripting of games (to give Funcionality and Logic into Gamemaps und such). I even made a pixeledtor in Lua for the PSP: http://www.node3000.com/digital-tools/download/smoove_pixel_tile_and_spriteeditor_for_sony_psp_psplua.php
>
>
>
>


Thanks, but unfortunatelly I don't have Jitter. MSP integration would be still nice. In fact the lib is a good example on the expressive power of Lua, but can't solve problems in max, because it's OpenGL suited.

On May 31, 2007, at 10:18 AM, Martin Wisniowski wrote:

> I was wondering why JavaScript - which coding is a pain - got such 

> prominent place in maxMSP, while Lua doesn't?

I find "which coding is a pain" odd. Lua and JS are *very* similar 

languages. I don't understand how coding in either one is fundamentally 

more of a pain than the other, so I assume it's just a personal 

preference. Most JS/Lua core language capabilities are easily moved 

from one to another. If you have a Lua code snippet of a task, I'm sure 

someone could show you how to accomplish in JavaScript.

> I think Lua is the perfect solution for scripting, doing logic or 

> mindles repetitive task, so thinking about Lua intergration instead of 

I suppose that everyone thinks their language of choice is the perfect 

one. As Wes stated, there's some provisional Lua support, and we're 

looking to make it easier to make language bindings in Max. It won't be 

"instead" of JS, but rather an optional "in addition to".

> I was wondering why JavaScript - which coding is a pain - got such 
> prominent place in maxMSP, while Lua doesn't?

I find "which coding is a pain" odd. Lua and JS are *very* similar 
languages. I don't understand how coding in either one is fundamentally 
more of a pain than the other, so I assume it's just a personal 
preference. Most JS/Lua core language capabilities are easily moved 
from one to another. If you have a Lua code snippet of a task, I'm sure 
someone could show you how to accomplish in JavaScript.

> I think Lua is the perfect solution for scripting, doing logic or 
> mindles repetitive task, so thinking about Lua intergration instead of 
> JavaScript would be neat.

I suppose that everyone thinks their language of choice is the perfect 
one. As Wes stated, there's some provisional Lua support, and we're 
looking to make it easier to make language bindings in Max. It won't be 
"instead" of JS, but rather an optional "in addition to".

Over the past months I've been prototyping a binding of Lua for audio 

synthesis, including an object for MSP ('lua~'). It appears to be 

more or less stable now, so if anyone is interested in beta-testing 

and giving feedback before a full release, please drop me a line. 

Currently only OSX (UB), but hope to have it compiled for Windows in 

A brief, semi-technical description for the curious:

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. Think algorithmic 

microsound, for example. The flexibility comes with a cost of 

course, but I was surprised how well it actually performs.

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.

Like jit.gl.lua, the plan is to support dynamic loading of extension 

modules, so that new C/Lua functionality can be written and added 

without needing to recompile lua~. If I can get my head around the 

details of dynamic loading on both OSX and Windows, that is.

Over the past months I've been prototyping a binding of Lua for audio  
synthesis, including an object for MSP ('lua~').  It appears to be  
more or less stable now, so if anyone is interested in beta-testing  
and giving feedback before a full release, please drop me a line.   
Currently only OSX (UB), but hope to have it compiled for Windows in  
the next few weeks.

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.  Think algorithmic  
microsound, for example.  The flexibility comes with a cost of  
course, but I was surprised how well it actually performs.

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.

Like jit.gl.lua, the plan is to support dynamic loading of extension  
modules, so that new C/Lua functionality can be written and added  
without needing to recompile lua~.  If I can get my head around the  
details of dynamic loading on both OSX and Windows, that is.


Quote: jkc wrote on Thu, 31 May 2007 20:11

----------------------------------------------------

> I suppose that everyone thinks their language of choice is the perfect 

When will we get Pascal and LISP support in Max/MSP?

(Sorry, couldn't resist; insert smileys as needed. And, actually, ELAN would be my PL of choice, but that's so wierd no one else will know it).

Quote: jkc wrote on Thu, 31 May 2007 20:11
----------------------------------------------------

> I suppose that everyone thinks their language of choice is the perfect 
> one. 

(Sorry, couldn't resist; insert smileys as needed. And, actually, ELAN would be my PL of choice, but that's so wierd no one else will know it).


Am 04.06.2007 um 21:05 schrieb Peter Castine:

On Jun 4, 2007, at 1:05 PM, Peter Castine wrote:

>> I suppose that everyone thinks their language of choice is the 

> ----------------------------------------------------

> When will we get Pascal and LISP support in Max/MSP?

> (Sorry, couldn't resist; insert smileys as needed. And, actually, 

> ELAN would be my PL of choice, but that's so wierd no one else will 

Personally, I'd vote for object-oriented FORTH support... ;) Heh, 

>
>> I suppose that everyone thinks their language of choice is the  
>> perfect
>> one.
>
> ----------------------------------------------------
>
> Yes! Yes!! YES!!!
>
> When will we get Pascal and LISP support in Max/MSP?
>
> (Sorry, couldn't resist; insert smileys as needed. And, actually,  
> ELAN would be my PL of choice, but that's so wierd no one else will  
> know it).
> --

Personally, I'd vote for object-oriented FORTH support... ;) Heh,  
heh, heh...

----
Steven M. Miller
Professor, Contemporary Music Program
College of Santa Fe

Home 
SFIFEM 
Atrium Sound Space 
OVOS 
CMP 

On 4 Jun 2007, at 20:17, Jeremy Bernstein wrote:

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.loadbang.net


http://en.wikipedia.org/wiki/Whitespace_programming_language

On Jun 4, 2007, at 5:08 PM, Nick Rothwell wrote:

> On 4 Jun 2007, at 20:17, Jeremy Bernstein wrote:

>
> On 4 Jun 2007, at 20:17, Jeremy Bernstein wrote:
>
>> And don't forget LOLCODE!
>
> I'm a bit more hardcore:
>
> 	http://en.wikipedia.org/wiki/Brainfuck
>
>
> Nick Rothwell / Cassiel.com Limited
> www.cassiel.com
> www.myspace.com/cassieldotcom
> www.loadbang.net
>
>
>
>


P.S. Fark and Something Awful are that way.

On Jun 4, 2007, at 5:56 PM, joshua goldberg wrote:

> On Jun 4, 2007, at 5:08 PM, Nick Rothwell wrote:

> pussy.
>
> http://en.wikipedia.org/wiki/Whitespace_programming_language
>
> On Jun 4, 2007, at 5:08 PM, Nick Rothwell wrote:

and let's not forget emoticon :-Q S:-P :-Q

http://www.teuton.org/~stranger/code/emoticon/emoticon.html

IMHO only Ruby and Python needs to be included.

> and let's not forget emoticon :-Q S:-P :-Q

http://en.wikipedia.org/wiki/Dark_ambient

On 6/5/07, nesa  wrote:
>
> and let's not forget emoticon :-Q S:-P :-Q
>
> http://www.teuton.org/~stranger/code/emoticon/emoticon.html
>
> KTHXBYE,
> nesa
>

-- 
http://en.wikipedia.org/wiki/Dark_ambient

Well thanks for this collection of exotic languages. At least I am glad to see something happen with that Lua thing. Thanks again.

Pascal is old school, Oberon is the way to go, and maxlisp exists

I'd be happy to be able to create externals in Oberon/ObjectiveC-Pascal.

When reading the SDK docs it seems that in theory it should be possible.

And there is an Oberon to C compiler, which seems a bit "von hinten

durch die Brust ins Auge", but it would probably create more efficient

code than an unoptimized native Oberon compiler...

> Personally, I'd vote for object-oriented FORTH support... ;) Heh, heh,

I guess you can write a forth interpreter in javascript, same for BASIC...

Peter Castine schrieb:
> When will we get Pascal and LISP support in Max/MSP?

Pascal is old school, Oberon is the way to go, and maxlisp exists
already (thanks Brad....)...
I'd be happy to be able to create externals in Oberon/ObjectiveC-Pascal.
When reading the SDK docs it seems that in theory it should be possible.
And there is an Oberon to C compiler, which seems a bit "von hinten
durch die Brust ins Auge", but it would probably create more efficient
code than an unoptimized native Oberon compiler...

Steven Miller schrieb:
> Personally, I'd vote for object-oriented FORTH support... ;) Heh, heh,

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Sounds cool Graham, I would be very interested in an XP 

Sounds cool Graham, I would be very interested in an XP 
version as well. Please keep us posted.


...when you remember your pass, kowing what you know today, the only logical result for that is dreamings about the future.

build an extarnal... an object capable of read and execute basic instructions.

it is possible to build a basic to c "translater"

wright basic...execute a real exeternal object.

it needs some basic new commands like inlet and outlet

and then... you run a patch and the object auto transform it self into a c++ and compiled object runnig in your patch...maybe with the temp file trick ;)

WHY NOT....to build a Max/MSP/JITTER to c++ translater and compiler. the translater, renders the patch code into an executable file, capable of runing by it self.... no max runtime... the real thing...

a progam language it's only a way to tell cpu to work... and cpu do not speak english.. so the translater has to exist.

when you live in harmony with you computer...

USER (you on your favorit chair... or at the bed...)

COMPUTER (a retro like speaking computer, like in alian! with sound fx and all...)

user: Want to build patch capable of taking coofee 'cause i only want to.

Computer: OK. hummm... do you want a milk and suggar calculator?

User: hummm... that's fine... and a temperature one too!

Computer: OK. I will start to compile the pach for you... do you want... hummm.... never mind!

build an extarnal... an object capable of read and execute basic instructions. 

it is possible to build a code mask.
it is possible to build a basic to c "translater" 

it needs some basic new commands like inlet and outlet
and then... you run a patch and the object auto transform it self into a c++ and compiled object runnig in your patch...maybe with the temp file trick ;)

'hollyhood's voice'
in the future...
a perfect future...
when you live in harmony with you computer...

computer: HELLO User!
user: Hi! 
user: Want to build patch capable of taking coofee 'cause i only want to.
Computer: OK. hummm... do you want a milk and suggar calculator?
User: hummm... that's fine... and a temperature one too!
Computer: OK. I will start to compile the pach for you... do you want... hummm.... never mind!

Sorry, I had to take lua~ down because it was having threading 

issues, which I'm working on resolving almost literally as I write 

this. Nothing wrong with the Lua engine, just something tricky about 

managing state between audio and message threads in Max (and in 

general really). As soon as that's done, I'll get an XP version up... 

On Oct 4, 2007, at 9:08 AM, Anthony Palomba wrote:

> Sounds cool Graham, I would be very interested in an XP

> version as well. Please keep us posted.

Sorry, I had to take lua~ down because it was having threading  
issues, which I'm working on resolving almost literally as I write  
this. Nothing wrong with the Lua engine, just something tricky about  
managing state between audio and message threads in Max (and in  
general really). As soon as that's done, I'll get an XP version up...  
should be in the next month I hope.

>
> Sounds cool Graham, I would be very interested in an XP
> version as well. Please keep us posted.
>

Lua intergration into next maxMSP version?