Pictured above is norns, a
sound computer music framework many-faced instrument1, from the folks at monome.
It runs scripts, little music-making apps, that anyone can develop and share through it package manager (maiden) and/or the community forum (lines).
Before deciding to acquire my own norns, I did some research to see what it was all about.
The official documentation (at the time2) was rather elusive, leaning more towards poetry than a technical reference.
I finally took the plunge but even after playing a bit with it, I still had a hard time pinpointing what I got my hands on.
As a matter of fact, norns can be many things, each script being mostly limited by its creator’s imagination.
For my own use, as I usually do with any subject matter3, I wrote down some notes as I got things figured out.
As I arrived pretty late in norns’ history, I was astonished by the shear number of scripts available.
To try them out and easily go back to them, I started cataloging those scripts.
It quickly became apparent that this effort could benefit to others, so I converted my notes to markdown (for easier collaboration) and made them public:
The reaction was pretty positive, and it sparked discussion with long time monome collaborators such as Sam Boling (post) and Dan Derks.
Early developments of norns.community
Still, it appeared that the official docs + the lines forum weren’t enough.
My effort got well received but wasn’t flexible enough to gain collaborative traction4.
As first theorized by Dan in this post, there was a need for more.
Overseen by Brian (@tehn), Dan and Tyler Etters started playing seriously with the idea of a wiki so that knowledge between script creators and users could be shared.
Before that, the forum was used for that purpose but it was tedious to find back technical information buried deep between more general conversation.
A wiki looked indeed like the best tool to create a shared memory, a common documentary heritage.
The idea was to use awesome-monome-norns as a baseline for the structure but to make it more script author-centered, notably allowing them to have space to document each of their creations.
At that time I got consulted by Dan on my views on how to structure information and that I could, if I wanted, be involved in the project in the future.
I shared with him some views I had gathered from my experience in the industry5 but didn’t really gave a clear feedback about being more involved.
I realized that one thing that was clearly missing from previous efforts (official doc, awesome-monome-norns) was a gallery view of all available scripts.
Indeed, they relied on lists or tables to present them. But all those scripts have a unique visual identity that is often more recognizable than their names.
I also wanted to address a common complaint I had with awesome-monome-norns: the table of connectivity options wasn’t legible enough with its many columns. A set of dedicated icons would make things both more compact and legible.
I gave myself a few hours over the weekend to make a working prototype, trying to respect as much as possible monome’s design language.
I presented it to Dan, who forwarded it to Tyler.
Both of them got hooked by the idea and got back to convince me of integrating it with the wiki.
At the time I got recontacted, Tyler and Dan had since made a huge effort on the data architecture side of things.
They asked me for advices on this aspect, but I didn’t see anything worth changing, so kudos to them.
Regarding the integration of the norns.gallery, on the other hand, things weren’t as smooth.
Firstly, one problematic aspect was how to share state (list of scripts and meta-data) between the 2 instances.
We quickly figured out that the wiki had an API that would solve the issue.
Secondly, we failed to clearly scope how the gallery would fit with the features provided with the wiki.
Indeed, the gallery was initially conceived as a search tool and there was an overlap of functionality with the wiki’s native tagging & searching system.
We initially thought that the latter was too limiting for the amount of search criterias we originally wanted6 and saw the gallery as a way to implement proper faceted search.
This early prototype still lives as an interactive demo.
However, we quickly saw several drawbacks:
- the wiki’s native tag system would be a pretty limiting meta-data structure7 for storing many different aspects (dimensions)
- imposing too many constraints on the proper tagging of script may have deterred contributors
- having 2 search interfaces would be counter-intuitive to end users
So we agreed to simplify and store only 2 aspects of scripts with tags: their category and their connectivity options.
Tyler then oversaw the integration of the gallery’s DOM as an embedded iframe.
In this process, he made it more responsive8, more compact and did some CSS touchups to make the whole thing appear seamless.
Furthermore, he pushed the idea of tighter coupling, making filtered versions for pages dedicated to authors and specific categories.
Going beta then live
Dan and Tyler invited several batches of script authors to register and add their creations to the platform.
It was rather satisfying to see their excitement as they proceeded and watch the gallery get automagically populated.
When we launched, the reception was very positive.
This first release was a success.
At the time of writing, from half to 2/3rd of all existing scripts have been documented. There is still some hidden gems that would benefit from being cataloged.
There is the eventuality of a tighter integration with norns package manager (maiden) that may tie a tighter link between norns as a platform and the community aspect of its script developments.
I would also be happy to see the wiki host more general information pages.
It could notably steal from awesome-monome-norns a list of engines and reusable Lua libs. (now done).
Ultimately I would like to mark awesome-monome-norns as deprecated, superseded by both the official doc and norns.community.
It was a pleasure interacting with Dan and Tyler on this project.
Tyler was especially impressive at how quick he was to grasp and patch the gallery’s source code, even though it was written in a foreign language to him (ClojureScript).
Dan struck me on one occasion with his intuition, leading us to a great optimization with a few innocent questions even though we were touching on a subject he had of us all the less know-how.
You can read Tyler’s post-mortem of the project on his blog.
You can check out their scripts on their norns.community pages:
If you have notes you keep to yourself, it might be worth it taking the extra step of sharing them with the world.
In addition to helping others, as a positive side-effect you might end up meeting other passionate people with whom you might sharpen your skills and grow as a person.
In the meantime, it got quite an overhaul, notably thanks to Dan. ↩
GitHub pull requests were not necessary the most user-friendly way to approach collaborative editing. ↩
As opposed to key/value(s) pairs or even a relational data model. ↩
Tagged #music, #monome, #information-architecture.