Hello all,
Thanks for all your amazing work on gem and continued development and exploration! I'm no "developer" but I use both both pd and gem for music and visual projects on a daily basis.
Does anyone know if it is possible to "draw" using pd/gem?
-meaning create a trail of changed colored pixels that are "triggered" from a moving point and persist until programmed to disappear or "cleared"-
best wishes from Romania (currently) and San Diego usually, Rick
Try single buffer drawing. Send a 'buffer 1' message to the gemwin before creating it.
On 9/16/07, rick snow ricksnow@gmail.com wrote:
Hello all,
Thanks for all your amazing work on gem and continued development and exploration! I'm no "developer" but I use both both pd and gem for music and visual projects on a daily basis.
Does anyone know if it is possible to "draw" using pd/gem?
-meaning create a trail of changed colored pixels that are "triggered" from a moving point and persist until programmed to disappear or "cleared"-
best wishes from Romania (currently) and San Diego usually, Rick
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hi! Otherwise, use pix_set, or so. Of course, there could be some kind of QuickDraw-like (tm Apple computer) commands in an object, or an object to which we can send OpenGL-like commands, such as Jitter's http://www.cycling74.com/documentation/jit.gl.sketch ... I might be interested on making one some day. We will see if I get some free time... :)
Actually, I am more interested in a Lua wrapper, from which we could use the OpenGL functions which would be rendered in the same render context than Gem's. Would it be easy? ClaudiusMaximus has started a wrapper for Lua, and I wonder if that would be easy to do. Wesley Smith has done the jit.gl.lua external ( see http://www.cycling74.com/twiki/bin/view/Share/WesleySmith ) which extends really well Jitter. It is not free (neither is Jitter), but it is a proof that adding some script language to a dataflow software makes things way easier when trying to make complex animations !! Calling OpenGL functions in text is nice, you know ! Way faster than using pd messages.
See : http://luagl.wikidot.com/
a
alexandre, at exactly this minute I was looking at exactly the same stuff, you just posted... a jit.gl.lua for gem (gl) would be cool. or python, but some scripting for gl would be cool. I still did not look into the shader language, maybe I will do this now... marius.
Alexandre Quessy wrote:
Hi! Otherwise, use pix_set, or so. Of course, there could be some kind of QuickDraw-like (tm Apple computer) commands in an object, or an object to which we can send OpenGL-like commands, such as Jitter's http://www.cycling74.com/documentation/jit.gl.sketch ... I might be interested on making one some day. We will see if I get some free time... :)
Actually, I am more interested in a Lua wrapper, from which we could use the OpenGL functions which would be rendered in the same render context than Gem's. Would it be easy? ClaudiusMaximus has started a wrapper for Lua, and I wonder if that would be easy to do. Wesley Smith has done the jit.gl.lua external ( see http://www.cycling74.com/twiki/bin/view/Share/WesleySmith ) which extends really well Jitter. It is not free (neither is Jitter), but it is a proof that adding some script language to a dataflow software makes things way easier when trying to make complex animations !! Calling OpenGL functions in text is nice, you know ! Way faster than using pd messages.
See : http://luagl.wikidot.com/
a
Hi, I think such a scripting possibility is a must.
Shaders are very - very- nice. They can allow you to modify the vertices (vertex shader) and textures (fragment shader) you send it. Furthermore, you can make it compute stuff, such as even physical simulation, on the GPU. What we need is an extendable way to create those vertices, and to choose the texture we put on it. By etendable, I mean that using a lot of [coll], [list] or so, and then [unpack]ing them is not so scalable. When you have something like 15 parameters on a sprite (a geo with a texture on it), you need something like a scripting language to keep track of the states, variables, changes, and such.
Now, if we call the void gl_lua::render(GemState *state) method of a gl_lua Gem object, and then call a lua function that draws vertices with a texture id (according to the GemState object attributes we pass it, I guess), would the result be drawn in the Gem window ?
I mean using the http://luagl.wikidot.com/ functions. I wonder if calling those : """ gl.Begin("LINES") gl.Color(1, 1, 0) gl.Vertex(0, 0) gl.Vertex(1, 1) gl.End() """" ... would work out-of-the-box. Would it ? If so, that worth it. :)
a
2007/9/16, marius schebella marius.schebella@gmail.com:
alexandre, at exactly this minute I was looking at exactly the same stuff, you just posted... a jit.gl.lua for gem (gl) would be cool. or python, but some scripting for gl would be cool. I still did not look into the shader language, maybe I will do this now... marius.
Alexandre Quessy wrote:
Hi! Otherwise, use pix_set, or so. Of course, there could be some kind of QuickDraw-like (tm Apple computer) commands in an object, or an object to which we can send OpenGL-like commands, such as Jitter's http://www.cycling74.com/documentation/jit.gl.sketch ... I might be interested on making one some day. We will see if I get some free time... :)
Actually, I am more interested in a Lua wrapper, from which we could use the OpenGL functions which would be rendered in the same render context than Gem's. Would it be easy? ClaudiusMaximus has started a wrapper for Lua, and I wonder if that would be easy to do. Wesley Smith has done the jit.gl.lua external ( see http://www.cycling74.com/twiki/bin/view/Share/WesleySmith ) which extends really well Jitter. It is not free (neither is Jitter), but it is a proof that adding some script language to a dataflow software makes things way easier when trying to make complex animations !! Calling OpenGL functions in text is nice, you know ! Way faster than using pd messages.
See : http://luagl.wikidot.com/
a
I don't know if it it works out of the box??? I just saw how this is done with jit.gl.lua. I am in a class with all Max users... but I don't care, do all my assignments in Pd. and I learn a lot! I do the vertex and fragment shader with the [glsl_vertex], [glsl_fragment], [glsl_program] and the rest with the GEMgl... objects. almost all gl commants exist as a GEM object. I also figured out how to do textures (finally), even multiple. still, scripting would be really good to have. marius.
Alexandre Quessy wrote:
Hi, I think such a scripting possibility is a must.
Shaders are very - very- nice. They can allow you to modify the vertices (vertex shader) and textures (fragment shader) you send it. Furthermore, you can make it compute stuff, such as even physical simulation, on the GPU. What we need is an extendable way to create those vertices, and to choose the texture we put on it. By etendable, I mean that using a lot of [coll], [list] or so, and then [unpack]ing them is not so scalable. When you have something like 15 parameters on a sprite (a geo with a texture on it), you need something like a scripting language to keep track of the states, variables, changes, and such.
Now, if we call the void gl_lua::render(GemState *state) method of a gl_lua Gem object, and then call a lua function that draws vertices with a texture id (according to the GemState object attributes we pass it, I guess), would the result be drawn in the Gem window ?
I mean using the http://luagl.wikidot.com/ functions. I wonder if calling those : """ gl.Begin("LINES") gl.Color(1, 1, 0) gl.Vertex(0, 0) gl.Vertex(1, 1) gl.End() """" ... would work out-of-the-box. Would it ? If so, that worth it. :)
a
2007/9/16, marius schebella marius.schebella@gmail.com:
alexandre, at exactly this minute I was looking at exactly the same stuff, you just posted... a jit.gl.lua for gem (gl) would be cool. or python, but some scripting for gl would be cool. I still did not look into the shader language, maybe I will do this now... marius.
Alexandre Quessy wrote:
Hi! Otherwise, use pix_set, or so. Of course, there could be some kind of QuickDraw-like (tm Apple computer) commands in an object, or an object to which we can send OpenGL-like commands, such as Jitter's http://www.cycling74.com/documentation/jit.gl.sketch ... I might be interested on making one some day. We will see if I get some free time... :)
Actually, I am more interested in a Lua wrapper, from which we could use the OpenGL functions which would be rendered in the same render context than Gem's. Would it be easy? ClaudiusMaximus has started a wrapper for Lua, and I wonder if that would be easy to do. Wesley Smith has done the jit.gl.lua external ( see http://www.cycling74.com/twiki/bin/view/Share/WesleySmith ) which extends really well Jitter. It is not free (neither is Jitter), but it is a proof that adding some script language to a dataflow software makes things way easier when trying to make complex animations !! Calling OpenGL functions in text is nice, you know ! Way faster than using pd messages.
See : http://luagl.wikidot.com/
a
Alexandre Quessy wrote:
I mean using the http://luagl.wikidot.com/ functions. I wonder if calling those : """ gl.Begin("LINES") gl.Color(1, 1, 0) gl.Vertex(0, 0) gl.Vertex(1, 1) gl.End() """" ... would work out-of-the-box. Would it ? If so, that worth it. :)
hmm, trying pdlua and luagl is not that difficult...at least for me it works.
(ok, i haven't done anything more complicated, like accessing Gem internal data (pixes!))
fgmad.r IOhannes
how does that work? what do I need? I downloaded something called LuaGL v1.01 but I have no clue, what to do with it? documentation is very little. do I have to compile something? It says I have to call the luagl library from within another program. ??? To many new unknown variables... marius.
IOhannes m zmoelnig wrote:
Alexandre Quessy wrote:
I mean using the http://luagl.wikidot.com/ functions. I wonder if calling those : """ gl.Begin("LINES") gl.Color(1, 1, 0) gl.Vertex(0, 0) gl.Vertex(1, 1) gl.End() """" ... would work out-of-the-box. Would it ? If so, that worth it. :)
hmm, trying pdlua and luagl is not that difficult...at least for me it works.
(ok, i haven't done anything more complicated, like accessing Gem internal data (pixes!))
fgmad.r IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
marius schebella wrote:
how does that work? what do I need? I downloaded something called LuaGL v1.01 but I have no clue, what to do with it? documentation is very little. do I have to compile something? It says I have to call the luagl library from within another program. ??? To many new unknown variables...
get lua
get pdlua, compile it, read the examples
get LuaGL, compile it (read http://sourceforge.net/tracker/index.php?func=detail&aid=1724422&gro... for instructions)
create a new lua-pdobject like this:
""" require('opengl')
local luagl = pd.Class:new():register("luagl") function luagl:initialize(name, atoms) self.inlets = 1 return true end function luagl:in_0(sel, atoms) if sel == "gem_state" then luagl:render() end end function luagl:render() gl.Begin("LINES") gl.Color(1, 1, 0) gl.Vertex(0, 0) gl.Vertex(1, 1) gl.End() end """
load it. have fun.
fmga.sdr IOhannes
marius schebella wrote:
IOhannes m zmoelnig wrote:
get pdlua, compile it, read the examples
IOhanes, thanks a lot! I will try to do that. It looks like this is not supposed to compile under macos out of the box? marius.
i have toadmit i have no idea. it doesn't compile for linux out of the box (i had to adjust the Makefile.common to add paths and correct the lua version it links to)
nevertheless, ask claude :-)
fma.sdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
get lua
get pdlua, compile it, read the examples
get LuaGL, compile it (read http://sourceforge.net/tracker/index.php?func=detail&aid=1724422&gro... for instructions)
create a new lua-pdobject like this:
""" require('opengl')
local luagl = pd.Class:new():register("luagl") function luagl:initialize(name, atoms) self.inlets = 1 return true end function luagl:in_0(sel, atoms) if sel == "gem_state" then luagl:render() end end function luagl:render() gl.Begin("LINES") gl.Color(1, 1, 0) gl.Vertex(0, 0) gl.Vertex(1, 1) gl.End() end """
load it. have fun.
This works?! Amazing. I just recently jumped onto the Lua train a bit. I see that there are several GL-bindings for Lua. Is luagl the one to use?
Ciao
Frank Barknecht wrote:
This works?! Amazing. I just recently jumped onto the Lua train a bit. I see that there are several GL-bindings for Lua. Is luagl the one to use?
i don't know as i haven't tried lua before yesterday.
the example works, but pdlua gives a lot of warnings and you cannot yet create a full-fledged (that passes on the GemList) gem-object in lua (both things because of the way pointers are handled)
mfa.dr IOhannes
Ciao
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
This works?! Amazing. I just recently jumped onto the Lua train a bit. I see that there are several GL-bindings for Lua. Is luagl the one to use?
i don't know as i haven't tried lua before yesterday.
Haha, me too. But I ordered the book now. Lua seems to be a very useful language to have for general scripting uses, and as it's extremely popular in game developement, I guess many possible Gem users might already be familiar with it and be able to make good use of it.
Ciao
On 9/19/07, Frank Barknecht fbar@footils.org wrote:
This works?! Amazing. I just recently jumped onto the Lua train a bit. I see that there are several GL-bindings for Lua. Is luagl the one to use?
Doesn't Python also have GL?
http://pyopengl.sourceforge.net/
Not sure if the calls require any special context to be created, but most things between glBegin() and glEnd() should work, albeit in a slightly dumb way.
Indeed it does,
I find this thread interesting because of the drawing I've been doing has been with stuff like texture feedback and repeat.
I started doing stuff with the gl headers, but what was missing (I realized) was the ability to create open-ended objects. Like a spline that gets longer and longer over time.
This means there would need to be more and more vertex() functions between glbegin() and glend() per frame.
Using the wrappers it means that a gemchain would get longer and longer over time, and have to be dynamically built. Possible, but certainly irritating.
The best "drawing" solution I can think of is an object that has an internal display list that operations (function calls) can be added to and removed from (like a linklist maybe). for example:
[12< | [until] | [t f f] | | | [random] # abstraction that sends 3 random numbers in a list | | | | [pack f f f f] | [add $1 vertex $2 $3 $4] # $1 is the index of this entry | [glDraw] (has glBegin and glEnd
You could set some of those wrapper flags (like GL_LINE_STRIP) via messages to glDraw, and a "add" message or something would add something to the linked list, that gets sorted and executed between glBegin and glEnd for *each* render cycle.
So the patch above would create a static 12 vertex structure where the vertex's are random, but not moving. You could add another vertex to it by doing "remove 11" (where 11 would be the last index of the last entry.) Insert could get ugly for managing the indexes...
Of course the number of vertexes would not be limitless, but it could do a pretty nice job...
Perhaps the arguments to "add" would be something different than GL, so each entry could be a vertex with all its attributes, rather than having to have a separate entry for the vertex, and its colour.
Just thinking aloud...
B.
chris clepper wrote:
On 9/19/07, *Frank Barknecht* <fbar@footils.org mailto:fbar@footils.org> wrote:
This works?! Amazing. I just recently jumped onto the Lua train a bit. I see that there are several GL-bindings for Lua. Is luagl the one to use?Doesn't Python also have GL?
http://pyopengl.sourceforge.net/
Not sure if the calls require any special context to be created, but most things between glBegin() and glEnd() should work, albeit in a slightly dumb way.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello,
B. Bogart a écrit :
Indeed it does,
I find this thread interesting because of the drawing I've been doing has been with stuff like texture feedback and repeat.
I started doing stuff with the gl headers, but what was missing (I realized) was the ability to create open-ended objects. Like a spline that gets longer and longer over time.
This means there would need to be more and more vertex() functions between glbegin() and glend() per frame.
on the Lsystem exemple, i use a message box to store a list of data to be draw at each frame. it's easy to add data to this list.
you can also use the same technic between gl_begin and gl_end with textfile.
resulting somthing like :
gemhead | t a a a | | | | | GEMglbegin | | | repeat | | | t a b | | | | | textfile | | | | GEMglvertex | GEMglend
increasing the repeat value when adding value to the textfile.
Using the wrappers it means that a gemchain would get longer and longer over time, and have to be dynamically built. Possible, but certainly irritating.
The best "drawing" solution I can think of is an object that has an internal display list that operations (function calls) can be added to and removed from (like a linklist maybe). for example:
[12< | [until] | [t f f] | | | [random] # abstraction that sends 3 random numbers in a list | | | | [pack f f f f] | [add $1 vertex $2 $3 $4] # $1 is the index of this entry | [glDraw] (has glBegin and glEnd
the last Lsystem exemple is a simple implmentation of this.
cyrille
You could set some of those wrapper flags (like GL_LINE_STRIP) via messages to glDraw, and a "add" message or something would add something to the linked list, that gets sorted and executed between glBegin and glEnd for *each* render cycle.
So the patch above would create a static 12 vertex structure where the vertex's are random, but not moving. You could add another vertex to it by doing "remove 11" (where 11 would be the last index of the last entry.) Insert could get ugly for managing the indexes...
Of course the number of vertexes would not be limitless, but it could do a pretty nice job...
Perhaps the arguments to "add" would be something different than GL, so each entry could be a vertex with all its attributes, rather than having to have a separate entry for the vertex, and its colour.
Just thinking aloud...
B.
chris clepper wrote:
On 9/19/07, *Frank Barknecht* <fbar@footils.org mailto:fbar@footils.org> wrote:
This works?! Amazing. I just recently jumped onto the Lua train a bit. I see that there are several GL-bindings for Lua. Is luagl the one to use?Doesn't Python also have GL?
http://pyopengl.sourceforge.net/
Not sure if the calls require any special context to be created, but most things between glBegin() and glEnd() should work, albeit in a slightly dumb way.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hi everyone, I've been following this thread with interest as I've been using Lua and LuaGL for about a year now. When I first started working with it, I spend quite a bit of time hunting down the best OpenGL bindings for Lua. Other one's like gllua are outdated or have strange interfaces. In the end LuaGL was the best I could find but it didn't wrap any of the extensions and has a few problems such as excessive use of malloc/free for dealing with float vectors and a poor conversion scheme between strings and enums. I recently joined the LuaGL project as a developer to work on these problems, but things are moving slowly and consensus is a hard to achieve right now.
As a result, the public release and SVN trunk could be improved quite a bit with a few straightforward changes. I have a branch of LuaGL in the project's sourceforge SVN repository with most of my improvements including support for extensions. I've compiled it on OSX and Windows but apparently there are some issues with Linux. It's not a polished release, but I have been using it in jit.gl.lua for quite some time so it is stable. Anyway, I thought I'd mention this since some people here seem quite enthusiastic about Lua for scripting GL.
Happy patching, wes
hi
Wesley Smith wrote:
I recently joined the LuaGL project as a developer to work on these problems, but things are moving slowly and consensus is a hard to achieve right now.
As a result, the public release and SVN trunk could be improved quite a bit with a few straightforward changes.
cool may i suggest one thing: please add a build-system to the trunk, even if it is not cross-platform yet. (what i found was in someones "private" branch, and the log-file said "not in trunk because not working on os-x" or something along these lines; isn't that why there are rcs? in order to be able to make small incremental changes? having a broken makefile is better than none, since people can probably modify them to work for them...)
fma.sdr IOhannes
Yeah. The build process is in jumbles with LuaGL right now. The project was dormant for about a year until I started talking to the original developer. Now we are 3 and working toward a release of the trunk with builds for Windows, OSX and Linux with make, visual studio, and xcode. Hopefully in the next few months this will be done.
wes
On 9/20/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
hi
Wesley Smith wrote:
I recently joined the LuaGL project as a developer to work on these problems, but things are moving slowly and consensus is a hard to achieve right now.
As a result, the public release and SVN trunk could be improved quite a bit with a few straightforward changes.
cool may i suggest one thing: please add a build-system to the trunk, even if it is not cross-platform yet. (what i found was in someones "private" branch, and the log-file said "not in trunk because not working on os-x" or something along these lines; isn't that why there are rcs? in order to be able to make small incremental changes? having a broken makefile is better than none, since people can probably modify them to work for them...)
fma.sdr IOhannes
Hi wesley, iohannes, I got pdlua compiled on mac intel using lua51, (I did not need luaGL to get it compiled..?) but when I create a [lua] object in pd i get an error (see below). I don't know if that error is related to my compilation or the missing luaGL. I also don't know how to compile luaGL. could I use the lua version that comes with jit.gl.lua? marius. ___ /Library/Pd/lua.pd_darwin: dlopen(/Library/Pd/lua.pd_darwin, 10): Symbol not found: _canvas_open Referenced from: /Library/Pd/lua.pd_darwin Expected in: /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd
lua ... couldn't create ___
Wesley Smith wrote:
Hi everyone, I've been following this thread with interest as I've been using Lua and LuaGL for about a year now. When I first started working with it, I spend quite a bit of time hunting down the best OpenGL bindings for Lua. Other one's like gllua are outdated or have strange interfaces. In the end LuaGL was the best I could find but it didn't wrap any of the extensions and has a few problems such as excessive use of malloc/free for dealing with float vectors and a poor conversion scheme between strings and enums. I recently joined the LuaGL project as a developer to work on these problems, but things are moving slowly and consensus is a hard to achieve right now.
As a result, the public release and SVN trunk could be improved quite a bit with a few straightforward changes. I have a branch of LuaGL in the project's sourceforge SVN repository with most of my improvements including support for extensions. I've compiled it on OSX and Windows but apparently there are some issues with Linux. It's not a polished release, but I have been using it in jit.gl.lua for quite some time so it is stable. Anyway, I thought I'd mention this since some people here seem quite enthusiastic about Lua for scripting GL.
Happy patching, wes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
To compile lua, you should be able to just download it and make on OSX. Be sure to add this flag during compilations: -DLUA_USE_MACOSX . This enables the dynamic loader in lua for loading Lua modules. You also might need this flag as well: -isysroot /Developer/SDKs/MacOSX10.4u.sdk It has been so long since I did a command line build of Lua. I use a framework build exclusively now built from an xcode project. Have you looked in the source files for canvas_load? I don't know where this comes from. This would be the first thing to figure out.
wes
On 9/22/07, marius schebella marius.schebella@gmail.com wrote:
Hi wesley, iohannes, I got pdlua compiled on mac intel using lua51, (I did not need luaGL to get it compiled..?) but when I create a [lua] object in pd i get an error (see below). I don't know if that error is related to my compilation or the missing luaGL. I also don't know how to compile luaGL. could I use the lua version that comes with jit.gl.lua? marius. ___ /Library/Pd/lua.pd_darwin: dlopen(/Library/Pd/lua.pd_darwin, 10): Symbol not found: _canvas_open Referenced from: /Library/Pd/lua.pd_darwin Expected in: /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd
lua ... couldn't create ___
Wesley Smith wrote:
Hi everyone, I've been following this thread with interest as I've been using Lua and LuaGL for about a year now. When I first started working with it, I spend quite a bit of time hunting down the best OpenGL bindings for Lua. Other one's like gllua are outdated or have strange interfaces. In the end LuaGL was the best I could find but it didn't wrap any of the extensions and has a few problems such as excessive use of malloc/free for dealing with float vectors and a poor conversion scheme between strings and enums. I recently joined the LuaGL project as a developer to work on these problems, but things are moving slowly and consensus is a hard to achieve right now.
As a result, the public release and SVN trunk could be improved quite a bit with a few straightforward changes. I have a branch of LuaGL in the project's sourceforge SVN repository with most of my improvements including support for extensions. I've compiled it on OSX and Windows but apparently there are some issues with Linux. It's not a polished release, but I have been using it in jit.gl.lua for quite some time so it is stable. Anyway, I thought I'd mention this since some people here seem quite enthusiastic about Lua for scripting GL.
Happy patching, wes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
canvas_load is a standard Pd function defined in m_pd.h. It's strange that isn't not found...
.hc
On Sep 22, 2007, at 2:11 PM, Wesley Smith wrote:
To compile lua, you should be able to just download it and make on OSX. Be sure to add this flag during compilations: -DLUA_USE_MACOSX . This enables the dynamic loader in lua for loading Lua modules. You also might need this flag as well: -isysroot /Developer/SDKs/MacOSX10.4u.sdk It has been so long since I did a command line build of Lua. I use a framework build exclusively now built from an xcode project. Have you looked in the source files for canvas_load? I don't know where this comes from. This would be the first thing to figure out.
wes
On 9/22/07, marius schebella marius.schebella@gmail.com wrote:
Hi wesley, iohannes, I got pdlua compiled on mac intel using lua51, (I did not need luaGL to get it compiled..?) but when I create a [lua] object in pd i get an error (see below). I don't know if that error is related to my compilation or the missing luaGL. I also don't know how to compile luaGL. could I use the lua version that comes with jit.gl.lua? marius. ___ /Library/Pd/lua.pd_darwin: dlopen(/Library/Pd/lua.pd_darwin, 10): Symbol not found: _canvas_open Referenced from: /Library/Pd/lua.pd_darwin Expected in: /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd
lua ... couldn't create ___
Wesley Smith wrote:
Hi everyone, I've been following this thread with interest as I've been using Lua and LuaGL for about a year now. When I first started working with it, I spend quite a bit of time hunting down the best OpenGL bindings for Lua. Other one's like gllua are outdated or have strange interfaces. In the end LuaGL was the best I could find but it didn't wrap any of the extensions and has a few problems such as excessive use of malloc/free for dealing with float vectors and a poor conversion scheme between strings and enums. I recently joined the LuaGL project as a developer to work on these problems, but things are moving slowly and consensus is a hard to achieve right now.
As a result, the public release and SVN trunk could be improved quite a bit with a few straightforward changes. I have a branch of LuaGL in the project's sourceforge SVN repository with most of my improvements including support for extensions. I've compiled it on OSX and Windows but apparently there are some issues with Linux. It's not a polished release, but I have been using it in jit.gl.lua for quite some time so it is stable. Anyway, I thought I'd mention this since some people here seem quite enthusiastic about Lua for scripting GL.
Happy patching, wes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
There are also some pixel based techniques that work,
look at 07.feedback and 08.MotionBlur
.b.
rick snow wrote:
Hello all,
Thanks for all your amazing work on gem and continued development and exploration! I'm no "developer" but I use both both pd and gem for music and visual projects on a daily basis.
Does anyone know if it is possible to "draw" using pd/gem?
-meaning create a trail of changed colored pixels that are "triggered" from a moving point and persist until programmed to disappear or "cleared"-
best wishes from Romania (currently) and San Diego usually, Rick
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
Alexandre Quessy -
B. Bogart -
chris clepper -
cyrille henry -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
marius schebella -
rick snow -
Wesley Smith