We are currently using Lua in an embedded system to define user interaction. The embedded application is a rather complex thing with a screen and a few hundred buttons, LEDs, encoders and faders, so user interaction can get messy. It all has to run on a single Blackfin processor.
Hence, there are serious memory constraints and processing power is very limited, too. But tell you what: Lua (no jit) does just fine.
User interaction is pretty complex. Most buttons have different functionality depending on context. Button presses can result in the screen content changing, LEDs changing, even motorized fader movements... More often than not, several dozens of hardware elements have to updated as a result of a single button press. Implementing all that in C++ would be a mayor pain.
We implemented a minimal framework in Lua that just barely looks like an object oriented system. It gets called with updates from the hardware ("Button A has been pressed") and responds by sending similar messages back ("Move Fader X to position Y"). Wrapping all that in some kind of convenient object system only took about 100 lines of Lua code. Interfacing that with the codebase took about 200 lines of C++ code.
We also use Lua to do string processing and value conversion ("display element D wants to display value F, but represent it on a logarithmic scale and convert it to SI units"). Implementing this can be done in something like 20 lines of C++.
So, a call into the Lua code will take a couple hundred cycles (yes, we have to count cycles), sometimes even a couple dozen thousand cycles. But for user interaction, that is perfectly fine. Some well-optimized C code could probably do the same thing quite a bit faster, but that would take ages to write and debug. (Plus, the bottleneck is not the Lua code. Loading images from disk, or moving faders takes considerably longer)
So, we are really happy with Lua.
But where Lua really shines is in its adaptability. The Blackfin does not support double precision math natively but Lua uses double as its standard data type. Well, you only have to change one #define, and Lua uses float instead. The Blackfin does not have an MMU, so we have to do some memory management manually. Well, you only have to change this one function and Lua will be fine with that.
A mixing console. The Lua is considered part of the software. It will not be exposed to the end user. It will however make it trivial for us to do quite complex modifications of the software without recompiling.
For example, displaying feet instead of meters is a trivial matter if all you have to change is some text/Lua files.
I also have to ask, with knobs and faders and sliders, is he making a synth or console or something? I've done something similar, although it never made it to market .. and I am very curious about how viable this is.
Of course, its viable to use Lua on a blackfin - what I meant was, what is your product? It sounds very interesting and I'd be happy to know of other examples of pro-audio gear using Lua and scripting languages in general, paired with a C/C++ core .. having built a few myself. :)
Ah, well from the perspective of someone interested in your product, I hope you'll give me enough hints that I'll recognize it when I see it on the market!
Hence, there are serious memory constraints and processing power is very limited, too. But tell you what: Lua (no jit) does just fine.
User interaction is pretty complex. Most buttons have different functionality depending on context. Button presses can result in the screen content changing, LEDs changing, even motorized fader movements... More often than not, several dozens of hardware elements have to updated as a result of a single button press. Implementing all that in C++ would be a mayor pain.
We implemented a minimal framework in Lua that just barely looks like an object oriented system. It gets called with updates from the hardware ("Button A has been pressed") and responds by sending similar messages back ("Move Fader X to position Y"). Wrapping all that in some kind of convenient object system only took about 100 lines of Lua code. Interfacing that with the codebase took about 200 lines of C++ code.
We also use Lua to do string processing and value conversion ("display element D wants to display value F, but represent it on a logarithmic scale and convert it to SI units"). Implementing this can be done in something like 20 lines of C++.
So, a call into the Lua code will take a couple hundred cycles (yes, we have to count cycles), sometimes even a couple dozen thousand cycles. But for user interaction, that is perfectly fine. Some well-optimized C code could probably do the same thing quite a bit faster, but that would take ages to write and debug. (Plus, the bottleneck is not the Lua code. Loading images from disk, or moving faders takes considerably longer)
So, we are really happy with Lua.
But where Lua really shines is in its adaptability. The Blackfin does not support double precision math natively but Lua uses double as its standard data type. Well, you only have to change one #define, and Lua uses float instead. The Blackfin does not have an MMU, so we have to do some memory management manually. Well, you only have to change this one function and Lua will be fine with that.