hi there, came across this thread today. I’m one of the authors of LuaAV (the one in the video to be exact). We are indeed working toward a new release (OSX / Linux) to be released at the end of the week. We have made our best effort to make all of our code that interacts with Lua as portable as possible, including the scheduling and audio engine. To use it in another app, you would need to link in libluaav and call a few functions on your lua_State to have access to the different modules embedded in the lib. The other modules that do image and video I/O, OpenGL, OpenCL, etc. are standalone binary modules, but to be useful require the lattice module embedded within libluaav. The concept of the lattice is to hold large blocks of arbitrary binary data. Lua itself doesn’t have such a data type, so we use it to pass around video frames, audio buffers, etc. between all the various media manipulating modules. This way, we can take a video frame and use it was a wavetable for example.
Here are some responses to questions in this thread:
LuaAV currently compiles on OSX and Linux. A Windows port wouldn’t be too painful as I have most of the code necessary stashed in some older branches. The Linux version is based on Qt for the app infrastructure, so this is what I would also use for writing the Windows version. The OSX version in based on Cocoa.
For editors, I personally use SubEthaEdit, but TextWrangler is also good. If you prefer Xcode, there’s a plugin for syntax highlighting available through the Lua Wiki.
There was a question about how it compares to LuaJIT. We use LuaJIT, so it doesn’t make so much sense to ask this question. The point of confusion may be around the fact that we also use LLVM. We’re not using LLVM to JIT compile Lua, but instead to JIT compile C/C++ code such that we can generate new Lua bindings are runtime. For example, if I want to dynamically compile a new unit generator, I can do so with LLVM but not LuaJIT since the ugen needs to be in C/C++ not Lua with how we’ve designed things.
You can talk to LuaAV as I mentioned above by embedding it with your own app, but if you want to talk to the standalone LuaAV app itself, you have to use some kind of inter-process protocol. OSC is a good choice IMHO. You won’t be able to share memory, but you can do interesting things by transmitting strings of Lua code through OSC and evaluating them on the receiving end. This is how we setup livecoding situations.
If anyone is interested in learning more, we have a mailing list you can sign up for on our site.