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.

mike

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ā€¦

To understand the criticisms better, I would like to understand what functionality you wanted your coder friend to write for your ā€˜one custom layout that you never need to changeā€™.

Iā€™m a coder. Like everyone else we are an opinionated bunch, and its very easy to pick at the decisions of other coders who wrote the stuff we then have to build on top of. There are also key differences between programming for small footprint, embedded systems, and things that programmers are used to in other domains. What one person may consider to be a clunky disgrace might actually be elegant and efficient when the device limitations and performance requirements are taken into account.

I dont have very high hopes for littlefoot evolution in future because not many people have shared useful things made with it, it probably hasnt driven sales, etc. And Roli are attempting to somewhat bridge the ā€˜pro-toy gapā€™ by focusing on more desktop software that doesnt require complex configuration or scripting, ie their line of Roli Studio apps. Dont get me wrong, I know that these will still be considered non-pro and Iā€™m not making any great claims about them, just looking at where Roli are going and their priorities.

Number one reason I did little with my blocks was not littlefoot, it was that the devices themselves didnt end up being that compelling to use for me, even if I had the full world of programmability available to them this wouldnt change much for me personally.

As for Lumi, if there is no littlefoot in it then its probably because there is perceived to be no need - the layout is fixed physically anyway, the output can all be very standard midi, and the lighting of the keys by other apps will hopefully be handled by sending standard midi messages to the Lumi (eg perhaps standard note on/off messages and the use of note on velocity value to set colour).

The big Lumi unknown for me, and perhaps the most likely cause of complaints to come, could be how the keys feel, the limited amount of travel to them, at what point the poly aftertouch kicks in, whether that stuff has any configurable curves etc. Hopefully I wont have too many weeks to wait till I find out for myself about this, since I have a couple on order via the kickstarter campaign.

Without going into boring (to everyone else) levels of detail: all I wanted was a set of four buttons that toggled on/off and four sliders, each sending its own MIDI CC message with its own color. Ideally one of those four sliders would be a bidirectional pitch ribbon with a dead zone at the center and return-to-zero ballistics; optionally one of the other ribbons might have had RTZ as well. My coder friend has discovered sets of third-party code blocks in Littlefoot that may well allow for such things, but since heā€™s poking at the Block in his spare time, I am not in any hurry.

His gripe, and mine, was that the tools for creating custom layouts as part of BLOCKS Dashboard were not tested properly. It is possible to code very small packages for the tiny amount of memory the Block uses (probably whatever the cache is on the controller chip), but the ā€œanyone can use itā€ tools build programs that are too big to fit in the Block. They work fine in virtualization when connected to the computer, but if you try to upload them to the Block, you get an error.

I will play with the LUMI when mine arrive and see what I think of it. Right now my attention is very much elsewhere. Even if they work well, I may well elect to sell them, since between my funding the Kickstarter and when theyā€™re likely to ship, the Hydrasynth came along and impressed the living crap out of me. :slight_smile: