Digital learning environments, Monome and Emacs

As I build the hyperlink.academy website, and we start to get specific about what it's going to look like, I've been drawing inspiration from other learning spaces that are fusions of technology and community. The two, drastically different, ones I'm writing about today are Monome and Emacs.

I know I've gone on about emacs but have I mentioned Monome in this newsletter before? They're a small company that makes some of the most beautiful musical instruments out there. Each piece of hardware they make is physically beautiful and lovely to touch and use. But they only truly comes alive as the gateway to beautiful software they've created

And when I say they, I don't mean just the small team. They've cultivated an incredible community around monome, called llllllll (or lines).

The two devices I own are the norns and the grid. The latter is a 8 x 16 grid of buttons, backlit by warm white leds. On its own it does nothing but send signals when buttons are pressed, and receive signals telling buttons to light up.

The Norns is where things come alive. It's a little computer, with a software stack tailored to making instruments. You plug grid into it, or a midi keyboard, or just use it's three onboard buttons and knobs. These inputs control scripts that make sounds.

Learning in Maiden

There are a lot of really important elements to the norns stack, but I'd like to focus on Maiden¹, the built-in programming environment. Once you boot up your norns, it hosts Maiden as a web interface you can access from your computer. ²

From here you can install scripts others have built and write your own. And, crucially, see and modify the source of every script you've downloaded. You can go from playing with a script, making some bleeps and bloops, to wondering "how did they do that", to seeing exactly how they did.

This makes for an incredibly satisfying learning loop. Combine it with the concise nature of the API's in the Norns library, and you can't help but have a smile on your face as you type a couple lines of code and transform the instrument you're playing with.

I've been slowly building a sequencer on the Norns. It's just a simple thing that plays 16 steps of 6 different sounds, but you can make some pretty fun beats with it. It started during my stint at the Recurse Center pair programming with a friend and I come back to it every couple months.

Each time I do I want it to be something different. First I had it store multiple beats, each with 16 steps (or notes) and have patterns of beats chained together to make longer songs. Then I threw that out and had it just have one giant beat with 256 "notes" that you could scroll around and make longer or shorter. I learned to make the entire thing by referencing the code others had written that already existed on my device, with a smidge of help from the excellent studies.

So about emacs

All of this reminds me strongly of emacs. Like I mentioned 2 weeks ago, emacs has the source code and documentation for almost every function available, and has built in ways to discover what things do.

I've been slowly trying to learn more elisp (the programming language emacs is written in), and I've been following a method quite similar to what I've been doing with Norns. I think of the action I've done closest to what I'm trying to do, and then go look at the code that makes it work. Like in with the Norns, this code's been written by someone out there in the community who wanted to make something they'd use. Then I try to make the smallest clone of it that still makes sense to me.

I'm still a lot earlier in the learning process for emacs than I am with the Norns, but already it's a lot of fun to puzzle through.

Some more takeaways

Together, emacs and the monome ecosystem provide a pretty exciting picture of technical learning environments. The combination of technologies for specific tasks, with features tailor made for learning, and communities that care makes for really powerful learning. So what are some specific things we can learn from them? These guesses are just a start, I'm sure there's a lot more:

1. Orient the community towards the long term

Emacs is probably the oldest piece of software I use on a daily basis, so monome can't quite compare to that. But, it's been around since 2005 and people still use and love the first hardware they sold. Because both have been around so long the community can trust that the time they invest, as learners and creators, is worth it. And so the ecosystems accumulate a ton of code to learn from.

2. Let people see "normal" artifacts

And all that code is written by normal end-users (as opposed to reading the source written by the developers). It's stuff I can relate to, and imagine myself coding. Each piece is a starting point for future learners.

3. Embed documentation everywhere

At any point, I should be able to figure out how any piece of that code works. This should work the same whether I want to learn how to use it or learn how to make it, because so often one blends into the other.

4. Reduce the time from curiosity to creation

The quicker I can go from how does that work tohuh that's cool and finally to huh that's cool and I'm doing it, the more the environment can metabolize learning.

How to actually use this

Now the real hard part is figuring out how to apply any of this to a general purpose non-programming based, learning community. I'll leave that as an exercise for next time.

P.S: Last week I accidentally left in a bit of metadata at the top of the newsletter. It was there as I'm now writing these newsletters primarily on my website, and then copying them into Buttondown. All the better to search and link them.