I got so frustrated with my Lightpad M that I finally sent it to a friend of mine who does coding for a living. He was curious about my constant complaints and was wondering if there was any way he could help me out, perhaps by brute-forcing a layout in Littlefoot that I could install and then never change, so at least it would be good for something other than propping up other controllers. His insights into the process since then have been fascinating to me.
First, he confirmed that the whole point of Littlefoot was to build workable code in a very very VERY tiny amount of RAM; our best theory is that ROLI devices are trying to put everything inside the 8K cache of whatever chip is controlling the device, so as to provide the leanest and fastest performance. Since you could add 128MB of RAM or more for a couple of bucks, the only reason not to would be to avoid having to address it.
However, he then got into dissecting some of the Littlefoot programs out there, and it’s been amusing and a little bit painful to read his status reports.
Blocks Dashboard is a program put out by ROLI so end users can program their own Lightpads and Seaboards without having to do coding. It offers a few basic options that are each Littlefoot programs, and the UI lets users change basic parameter values. Interestingly, it routinely creates configurations that work fine when virtualized on your computer but are too big to download into your Block.
My friend discovered that this was not an inherent failing in Littlefoot – he was able to find snippets of code written by users that could do fairly complex operations with room to spare – but instead was due to the fact that the Dashboard program was written with no optimization at all in it, and was apparently never checked to work properly by ROLI. They assumed that if the virtualization worked, then the programs worked. I would love to be proven wrong about this.
Further, he discovered limitations in the language that make some seemingly obvious design choices, like creating multiple copies of an interface element like a fader that address non-contiguous MIDI Channels or data types, impossible or at least very difficult. He went on to describe several other glaring problems in how the program did various kinds of data handling, most of which flew right over my head but had fellow professional coders shaking their heads and laughing.
In his last message, he said that he was battling a growing urge to rewrite the whole language and post it somewhere just to piss off ROLI. That was three weeks ago and I haven’t been able to contact him since. I am getting worried.