Wow Claude, last night I rewrote several of my old externals that were originally in C, in Lua last night... And they required about 1/4 of the code that C requires. I am pretty much sold on using Lua now... I guess one of the things that seemed to scream out at me was "How would Lua and PD work together"? While I know this is a pretty broad and general question, I was wondering, with you as the developer of the Lua stuff, just how do you see Lua fitting in with PD? What sorts of things would be best done in each language? One of the things that I like (if I understand this correctly) about using Lua, as that everything is now accessible programmatically.
I do have a couple of questions...
- Is it possible to access from Lua, the elements of a table object that is
defined in PD? 2. Can data struct's be accessed from Lua? 3. Is it possible to load Lua objects using a path? (ie [my-lua-directory/my-lua-external.lua]) If something written in Lua is supposed to look like other PD externals, then I would think this would work with Lua externals as well. 4. Are there things that you wouldn't do in Lua? For performance reasons? Other reasons?
I guess I am asking these things because I could see it possible that I could rewrite almost everything in Lua, and then passing on the control data to the PD objects to generate the sound. One of the "line of division" that I was thinking about for my own stuff would be to write all the control stuff in Lua, and then feed that data to PD for the audio generation.
Thanks for this work you have done (and to others, as well).
Mike
Mike McGonagle wrote:
Wow Claude, last night I rewrote several of my old externals that were originally in C, in Lua last night... And they required about 1/4 of the code that C requires. I am pretty much sold on using Lua now...
Cool :-)
I guess one of the things that seemed to scream out at me was "How would Lua and PD work together"? While I know this is a pretty broad and general question, I was wondering, with you as the developer of the Lua stuff, just how do you see Lua fitting in with PD? What sorts of things would be best done in each language?
I use C for things requiring lots of numerical computations.
I use Lua for things requiring a more dynamic language, for example handling multi-modal keyboard input. Also for processing small arrays in ways that would be awkward with Pd-implemented loops.
I use Lua for string processing in general, as C is horrid for that.
One of the things that I like (if I understand this correctly) about using Lua, as that everything is now accessible programmatically.
I think you mean that you can change things within Lua at runtime more readily than in C? This is true, it's also true that dynamic typing can lead to more subtle bugs than C's static typing.
I do have a couple of questions...
- Is it possible to access from Lua, the elements of a table object
that is defined in PD?
Not yet, but it's pretty high on the TODO list (at least the one in my head).
- Can data struct's be accessed from Lua?
Not yet, and I'm not sure if that will ever be safe, even if it is possible. There was a prominent warning in an earlier version of pdlua that stated "pointer atoms are untested/unsafe", but I removed it by request, as other externals are in the same category but don't warn the user.
- Is it possible to load Lua objects using a path? (ie
[my-lua-directory/my-lua-external.lua]) If something written in Lua is supposed to look like other PD externals, then I would think this would work with Lua externals as well.
Have you tried it? I have a hunch that it might Just Work (TM), if not then let me know and I'll investigate.
- Are there things that you wouldn't do in Lua? For performance
reasons? Other reasons?
Vast amounts of number crunching, for performance reasons. This includes DSP at the moment, although hopefully Frank's port of Lua~/Vessel~ is a viable alternative (not sure what the current status of that is).
System calls, for "Lua doesn't have C structs" reasons - you'd have to write C code for them to call them from Lua anyway, so not much point.
I guess I am asking these things because I could see it possible that I could rewrite almost everything in Lua, and then passing on the control data to the PD objects to generate the sound. One of the "line of division" that I was thinking about for my own stuff would be to write all the control stuff in Lua, and then feed that data to PD for the audio generation.
Yes, that seems a sensible approach. Just in case, note that it's no sin to split the Lua code into multiple classes and connect them together as separate objects inside a Pd patch - modularity is a good thing.
Thanks for this work you have done (and to others, as well).
Thanks for the feedback,
Claude
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
Mike McGonagle wrote:
Wow Claude, last night I rewrote several of my old externals that were originally in C, in Lua last night... And they required about 1/4 of the code that C requires. I am pretty much sold on using Lua now...
Cool :-)
I guess one of the things that seemed to scream out at me was "How would Lua and PD work together"?
My opinion: pdlua is the best thing that happend to Pd since [list].
That's quite a mouthful but I'm serious about that. IMO Miller should bundle lua with pd-vanilla just like [expr]: It only requires ANSI-C, and the statically linked binary is about the same size as expr.pd_linux while being so much more expressive (pun not intended). Lua (the language) and Pd share a lot of philosophical viewpoints, like scepticism in regard to threads, the "compact is better than complicated" approach, easy extensibility, simple syntax, etc. If you read for example the chapter on modules and namespaces in the Lua PiL-book a lot of similarities turn up. Pd might be able to learn more from Lua in this than from languages like Python or Java.
- Are there things that you wouldn't do in Lua? For performance
reasons? Other reasons?
Vast amounts of number crunching, for performance reasons. This includes DSP at the moment, although hopefully Frank's port of Lua~/Vessel~ is a viable alternative (not sure what the current status of that is).
It is working fairly well and now that LAC is almost over I intend to work more on it as I want to use it in a project. Vessel is quite fast: All synthesis and number crunching happens in a C-library, while Lua just serves as a kind of text based patching environment for dynamically generating the dsp graphs. This is very handy for granular synthesis or any other tasks that require lots of polyphony. So Vessel can do things that are nearly impossible with Pd patching alone.
Ciao
Frank Barknecht _ ______footils.org__
On Wed, Mar 05, 2008 at 09:45:47AM +0100, Frank Barknecht wrote:
Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
Vast amounts of number crunching, for performance reasons. This includes DSP at the moment, although hopefully Frank's port of Lua~/Vessel~ is a viable alternative (not sure what the current status of that is).
It is working fairly well and now that LAC is almost over I intend to work more on it as I want to use it in a project. Vessel is quite fast: All synthesis and number crunching happens in a C-library, while Lua just serves as a kind of text based patching environment for dynamically generating the dsp graphs. This is very handy for granular synthesis or any other tasks that require lots of polyphony. So Vessel can do things that are nearly impossible with Pd patching alone.
Really excited to try this out!
Chris.
me too, really excited to see lua signal processing in pd. since graham wakefield is involved I guess it will be similar to the max version? are you planning a native texteditor support from within pd. I saw texteditors that pop up when you double cklick an object for example for the cyclone coll object. something like this (... syntax highlighting???). auto updating of scripts when they are changed and saved would be nice, too. marius.
Chris McCormick wrote:
On Wed, Mar 05, 2008 at 09:45:47AM +0100, Frank Barknecht wrote:
Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
Vast amounts of number crunching, for performance reasons. This includes DSP at the moment, although hopefully Frank's port of Lua~/Vessel~ is a viable alternative (not sure what the current status of that is).
It is working fairly well and now that LAC is almost over I intend to work more on it as I want to use it in a project. Vessel is quite fast: All synthesis and number crunching happens in a C-library, while Lua just serves as a kind of text based patching environment for dynamically generating the dsp graphs. This is very handy for granular synthesis or any other tasks that require lots of polyphony. So Vessel can do things that are nearly impossible with Pd patching alone.
Really excited to try this out!
Chris.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Even better would be to use file associations to open the file in
your default Lua editor.
.hc
On Mar 5, 2008, at 10:27 PM, marius schebella wrote:
me too, really excited to see lua signal processing in pd. since
graham wakefield is involved I guess it will be similar to the max version? are you planning a native texteditor support from within pd. I saw texteditors that pop up when you double cklick an object for example for the cyclone coll object. something like this (... syntax highlighting???). auto updating of scripts when they are changed and saved would be
nice, too. marius.Chris McCormick wrote:
On Wed, Mar 05, 2008 at 09:45:47AM +0100, Frank Barknecht wrote:
Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
Vast amounts of number crunching, for performance reasons. This includes DSP at the moment, although hopefully Frank's port of Lua~/Vessel~ is a viable alternative (not sure what the current
status of that is).It is working fairly well and now that LAC is almost over I
intend to work more on it as I want to use it in a project. Vessel is quite fast: All synthesis and number crunching happens in a C-library,
while Lua just serves as a kind of text based patching environment for dynamically generating the dsp graphs. This is very handy for
granular synthesis or any other tasks that require lots of polyphony. So
Vessel can do things that are nearly impossible with Pd patching alone.Really excited to try this out!
Chris.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
Hallo, marius schebella hat gesagt: // marius schebella wrote:
me too, really excited to see lua signal processing in pd. since graham wakefield is involved I guess it will be similar to the max version?
Yes, it's practically the same objectclass. For now it's called [vessel~] instead of [lua~] but that might change.
are you planning a native texteditor support from within pd. I saw texteditors that pop up when you double cklick an object for example for the cyclone coll object. something like this (... syntax highlighting???).
I won't do this: The tk-editor is not very usable and other editor widgets would add dependencies I'd like to avoid. Most people will want to use their favourite editor anyway.
Maybe it's possible to use os.execute() in scripts on your own to start an editor, but it also may introduce platform issues.
auto updating of scripts when they are changed and saved would be nice, too.
That could be useful, but it's not high on my todo list for now.
Ciao
Frank Barknecht _ ______footils.org__
On Mar 6, 2008, at 8:30 AM, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
me too, really excited to see lua signal processing in pd. since
graham wakefield is involved I guess it will be similar to the max version?Yes, it's practically the same objectclass. For now it's called [vessel~] instead of [lua~] but that might change.
are you planning a native texteditor support from within pd. I saw texteditors that pop up when you double cklick an object for example for the cyclone coll object. something like this (... syntax highlighting???).
I won't do this: The tk-editor is not very usable and other editor widgets would add dependencies I'd like to avoid. Most people will want to use their favourite editor anyway.
Maybe it's possible to use os.execute() in scripts on your own to start an editor, but it also may introduce platform issues.
auto updating of scripts when they are changed and saved would be
nice, too.That could be useful, but it's not high on my todo list for now.
Ciao
It seems to me that the ideal would be to have access to the Pd DSP
API in pdlua, then you can just write tilde objects in lua. I don't
really know how hard that would be.
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
-
Chris McCormick -
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
marius schebella -
Mike McGonagle