Re: [ANN] LuaAV OSX binary release

[Graham Wakefield <wakefield@...>]

Exactly. The need for some kind of Array type (some general way to pass large chunks of data around) was a long-standing challenge we've had with the otherwise wonderful Lua language.  It's a tempting possibility that when luajit's ffi is working, that we can talk 'Array' in that way as well / instead. Depending on how the luajit-ffi ends up looking, of course. However, it would be good not to be dependent on luajit exclusively also.

Graham

PS. some of the modules are built into libluaav itself (OSC, MIDI, Clang etc.), but could be lifted out without too much pain. Keeping them inside the library made linking issues disappear.
Some other modules are pure Lua, so should be much easier to extract!

On Jan 3, 2011, at 8:18 PM, Wesley Smith wrote:

>> Are the individual modules generally usable in isolation (or in small
>> sets)?  Some of those modules look tasty, but no way do I want a
>> dependency on a huge "environment"...
> 
> The answer is yes with one caveat: most modules depend on the Array
> module.  Any module that deals with buffers of data like images, video
> frames, geometry buffers, need the Array module.  If you want to use
> any of these modules, you'll have to have the Array module and its
> corresponding header file so that the other modules have a definition
> of Array.  The idea here is that we didn't want one large monolithic
> module containing opengl, video, image, etc, so we designed a header
> file with the definition of C/C++ objects for passing around memory
> buffers and a lua module for manipulating them in scripts.  The
> relevant files are:
> 
> http://www.mat.ucsb.edu/projects/luaAV/browser/trunk/dev/include/lua_array.h
> http://www.mat.ucsb.edu/projects/luaAV/browser/trunk/libluaav/src/lua_array.cpp
> 
> There are some dependent headers but not that many.  If you want to
> use them in your app, it should be pretty easy.  If there's something
> that needs changing in order to make it work, we're happy to have any
> patch submissions.
> 
> wes
>