Littlefoot, oh, Littlefoot

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.


1 Like

Uuuu he was snatched by some life form right before Roli could get to him :wink: … novelize…

Last months I have settled my Lightpad M with that “ Axyz Gems” ; it’s just that.

1 Like

My take on this is different than yours. I see Littlefoot scripting as a bonus, and a very cool one at that. While there will always be room for improvements, giving the end users the option to tinker is much better than not having that ability at all. With a dedicated editor, a very easy to grasp scripting language and decent documentation, this side of the Blocks were a pleasant surprise to me. Basically, if you know C, making stuff for the blocks takes very little effort.

As for the specific hardware and language features, I suspect the opinions from an electronics engineer or some developer working with embedded systems would be very different from what (I am just assuming here) you got from a “modern-day” software developer. Their world is very, very different from writing code for electronics.

I don’t include you in the following group, but I often see rants from non-developers being frustrated by some piece of gear/software that opens up for end user tinkering. I see variations of the same complaints with the Blocks, EigenD and even Axoloti(!). I’m worried that in the long run this negativity could actually be harmful as it might discourage companies from provide this kind of features at all. Staring blankly at a screen for hours at end, wondering why some crap doesn’t work/work in some stupid way is just another day at work for most devs. For someone not used to this the experience might be very frustrating. Sometimes this frustration is unfairly directed at the product/company, (but of course, sometimes it is completely fair).

1 Like

It’s been a long time since I looked at littlefoot - I think my interest in it diminished when I realised that their stock Seaboard Block MPE functionality was not written in littlefoot so I could not simply tweak the existing code to suit my needs (some of it was in littlefoot but the core MPE midi note etc handling was just one line of code calling a single function). Obviously its intended purpose is far more for the lightpads than the seaboards, and although I have some of those I’ve done very little with them. I wonder if the Lumi will use any of this stuff.

@Kai thank you for not including me in that group, and I think your points are valid, but this gets back (AGAIN) to the damn bimodal distribution of how ROLI approaches their products. Either you have to be a complete noob using what’s provided for you, or you have to be a coder. The issue I have with this is that the tools ROLI provides to the noobs are broken. That’s lazy, careless, and rude.

I don’t know C… C was very young and wasn’t a commonly available option yet, the last time I did serious programming… and at my age, I have too many other things to accomplish to take time out to learn it. I applaud musical coders, but I will never be one. And I shouldn’t have to become one in order to fix the “anyone can set up a Lightpad to do what they want” tools provided by ROLI for the very people they’re trying to encourage to use their products.

@SteveElbows I fervently hope the Lumi doesn’t use ANY of this stuff. I want it to be dumb as a doorknob, sending reliable velocity, poly aftertouch, and release velocity data that can be massaged by something else. Anything beyond that is likely to backfire, based on current evidence.

I’m waiting on a LUMI, and i really hope it has something ‘like’ Littlefoot :wink:

Im with @Kai here,
whilst I agree that Roli have probably ‘oversold’ Littlefoots use to non-developers, at least it provided developers a way to alter the firmware. there is nothing wrong in my book with having open firmware that can be ‘hacked’ by experienced developers - and then shared back to the community.
It’ll be a loss to the community as a whole, if Roli make the firmware completely closed.

however, i do not think a ‘open firmware’ is an excuse for lack-lustre implementation(*),
even with open firmware, I expect a lumi to have solid velocity, poly at, release velocity.

(*) its frustrating when you see companies use open-source as an excuse for an incomplete product (‘the community can build it’)

1 Like

That’s my whole point here. I am not arguing against the principle of opening the platform, but ROLI has done it so very badly! I would rather they leave the Lumi alone and functional than do something bass ackwards that makes it less usable…