Yes, that’s the plan. Wait till its stable, test if it works for us, then use it. Luajit2 actually is only interesting for us for DSP/realtime stuff. For everything else, Lua is more than fast enough. Main bottlenecks in the API we have now is the API itself, not Lua.
We use Lua 5.1, so even if Luajit does not support 5.2 this is not a big deal for us.
1-2 weeks - Release of LuaJIT 2.0.0-beta6 (features)
Q1 2011 - Release of LuaJIT 2.0.0-beta7 (stability)
Q1-Q2 2011 - ARM port of LuaJIT 2.0
Q1-Q3 2011 - Some more beta releases for LuaJIT 2.0
Q3 2011 - Release candidate of LuaJIT 2.0
Q3-Q4 2011 - Release of LuaJIT 2.0.0 final
Q4 2011 - Work on LuaJIT 2.1 starts
Please note this is a tentative schedule, for your orientation only!
I cannot give you any guarantee whatsoever for the correctness of the
Now that LuaJIT 2.0.0-beta10 is out, a couple of reorganizations
will happen in the source tree. After that, one new optimization
and two new ports will be added.
These are (probably) the last major changes to LuaJIT 2.0 before
the final (non-beta) release. All other planned features will have
to wait for LuaJIT 2.1.
I’d dispute that the speed is only relevant to DSP/realtime stuff. When I was experimenting with lua for algorithmic composition stuff, I was pounding high LPB patterns with generative pattern data, and the slow speed got to be pretty tedious. I don’t think anyone other than myself would have tolerated the wait times.
I was wondering the same, maybe there is stuff going on under the hood but it’s kept under wraps for now, the new scale options are essentially midi processing so maybe they will expose that one day and then we can write our own midi processing tools!