Earlier today: where things are.

There are some rough edges, but a lot of things are working. When it’s good, it’s very good.

Here’s one use of Twinklr.

I’m running the software on my computer, rather than the final box, and using a remote encoder. I’m spitting MIDI out of Twinklr and into a MIDI-CV adaptor, which is then playing notes on the modular synthesizer. Two playheads are moving in opposite directions; as I play, I tweak the attack of the envelope.

A good few weeks on Twinklr. For starters, I've got a working development crank handle. And the software's motoring ahead; I think we'll have multiple scales working by next week.

We had our first MV Works crit this week, which was great - really exciting to see the very different approaches everybody's taking, and also to get some useful insight from other teams.

It also helped me pull some thoughts together, and in particular, to remember that whilst it's great I've got a big list of features to crank out, having space to play and develop ideas off the roadmap is important. So I'm going to make sure I carve some space out for those.

The next few weeks are going to be about getting to a passable stopping point with the software - essentially, scales and save/load for now - and then getting a slightly more satisfactory version running on the Raspberry Pi. I poked the Pi enough to know things'd work, but now I'd really like to make things work correctly, and to do that, I'll just need to schedule in some time.

Richard was down on Wednesday so we talked about progress, he seemed pleased, and also had some ideas about where to take the UI, so I'm looking forward to seeing where he takes it.

A few days' work at the end of the year, and some progress to report.

The Raspberry Pi appeared to be struggling a bit under the original Twinklr code. That's likely because the whole thing was a big HTML5 Canvas element, and that meant re-rendering all the pixels every frame inside Chromium.

So I decided to rewrite the whole code to use SVG instead. This makes sense for a few reasons:

the art style can easily be implemented entirely with basic SVG elements, so it felt like an easy fit.

the rendering code becomes far more efficient - rather than updating unchanged pixels, we just make objects appear and disappear from the DOM.

it becomes easier to implement animation thanks to using a library such as Snap to tween SVG attributes

by moving to defined DOM objects (rather than cluster of pixels), we also move to a more object-oriented representation of the domain model. This makes a few features we're interested in prototyping (such as multiple playheads) much easier to implement, and, in general, meets some of my goals for making the code easier to build upon in the future.

So nothing particularly fancy, but I'm at the point I want to be for January - the software's now entirely into implementing new things territory.

I also spent far too long staring into the abysses of electronics component sites, but think I've come to a decision on where to begin with rotary encoders, and prototyping some of the hardware. I also got shown how to use the laser-cutter, and by the end of the year, had got a bit of a workflow from going from Fusion360 CAD into laser-cut objects; there's going to be lots more learning to do there, but I'm making decent progress.

Quick upload from the phone camera for work in progress.

This is what I’ve done in the past couple of days on/off.

What this is: the Twinklr 1.0 code (ie, where we were at the beginning of MV Works) running on a Raspberry Pi. That’s Chromium running at fullscreen, and an official 7″ touchscreen. I’m interested in seeing how the touchscreen performs - and how the Pi works out. Also, documenting the process for repeatbility.

The good news is, so far, the thing works, and it’s a starting point, and we’ll continue to tinker.