New to monome, and monome + modular: ask questions here

Less Concept is a blast for starters!


Hoping for some guidance please;

I have just acquired a Digitakt and want to get midi communication going with my Eurorack system, I have Teletype, Ansible, Crow and Sweet Sixteen but no dedicated midi2CV module.

How should I go about it? I read Teletype would be the most flexible way to handle Midi, but could Sweet Sixteen handle midi messages and send them to the system via i2c for example?

ansible is a MIDI to CV module.



Thank you for the pointer.

Edit: to whomever happen to acquire a new Digitakt and Ansible (and not do preliminary research like me!), Digitakt can only handle Midi via Midi Din and not Midi USB. You would need either a USB to Midi conversion cable. There may also be a way to use a module like @attowatt 's i2c2midi only with Ansible but I am unsure…

1 Like

Hello – I have no experience with Monome. I’ve just been reading about the ecosystem and I’m getting the idea that Norns + Crow could offer some long-sought powers. The amount of info is a little overwhelming. I hope someone can help me with a few questions?

I am comfortable with coding. (I’ll admit that I found SuperCollider… unintuitive. But I’m willing to hit it again).

– Is there a limitation to the complexity of Crow scripts?
– “Presently” only a single Crow can be driven from a Norns. Do we know anything about the likelihood of that changing in the future?
– Is it possible to have a Crow script that accepts or sends MIDI notes via its USB port, or is that port only for talking to Norns/computers/etc?
– Can Norns audio outputs pass CV? ie are they DC-coupled?
– So Norns is running SuperCollider… can we say anything about how powerful Norns is? Is there a noticeable performance gap between Norns and a computer running SC? Is there a noticeable performance gap between Norns and Norns Shield?

I see that Crow v3 has support for multiple clocks, frequency trackers and just intonation. My first move would probably be to get one and do some experiments driving a modular synth. Eurorack is an alarmingly large and complicated zone that I’m unfamiliar with. I would welcome any suggestions for a very small Eurorack enclosure, ideally one with a lid that fastens on.

Thank you, lines.


hi! welcome + happy to help!

i felt the same way for a very long time, but thankfully scripting for norns is split into two basic buckets: SuperCollider for creating synths, Lua for controlling them. for the first three years of my norns journey, i didn’t code anything in SuperCollider directly – i 100% relied on the existing community synth engines or just building sequencers which spoke MIDI. thanks to the studies, i was able to learn how to use Lua to describe what should happen with those synths, rather than learn SuperCollider to learn how to make my own synths (and really, all my needs were met by the existing engines + softcut).

that said, SuperCollider rules and is an insanely powerful DSP tool. the stuff that @infinitedigits has been doing is massively inspiring. a lot of the techniques he uses are captured in these two introductory workshops he facilitates for Music Hackspace: Tone to Drone and Ample Samples.

crow can support a Lua script up to 16kb in size, which is ~700 lines. most crow scripts (eg. the ones in bowery provide really good examples) are less than 100 lines.

crow does not, unlike norns, have an architecture that allows a main script to reference other custom Lua code in additional files (via include or require).

crow 3.0 introduced a LOT of really wild built-in libraries, though, which drastically reduce the required complexity of a crow script – eg. audio rate oscillators, a unique approach to sequencing data, and a brilliant language for describing complex slopes. trent’s maps series stitches these together in really compelling ways, highly recommend!

this’ll require a bit more architecting, since it’s not just about addresses but also on-screen menu UI and system convos. it’s still on the radar, afaik!

that port is for connecting to a host only, eg. norns/computer. when paired with norns, it’d be straightforward to write a very tiny norns script that converts CV sent to crow as MIDI or MIDI sent to norns as CV for crow. as far as connecting crow with general purpose computers goes, we have Max objects + Max for Live devices available for crow which perform these functions. there’s also a possibility that crow could be seen as a USB MIDI device by a connected computer in the future.

outputs are not DC-coupled (more info on outputs here). crow is the most-tightly-integrated CV companion for norns.

norns is powered by a Raspberry Pi 3B. this presents limitations that a recent laptop would blow past, but honestly none that restrict what folks are able to create (Sway, Mx.Samples, Dronecaster, Tviburar all come to mind).

but also, norns isn’t meant to compete with a laptop running SuperCollider – the Lua API and the built-in libraries are what makes it powerful, to me. as a person with near-zero coding experience, i found it very approachable to spin up a compelling performance interface or a unique sequencer when i first dove in years ago. i personally wouldn’t have been able to travel as far or as quickly within other creative code paradigms. i can imagine that as someone already comfortable with code, you’ll have more fun than worry :slight_smile:

there are no performance differences between the two.

fwiw, i have a SIX_60 // 6U 60HP – BLACKHOLE CASES (in blue) which i love. just the right size without doing hp golf. it might also be interesting that the Moog 60hp case fits very very very well inside of the Nanuk 920 with diced foam.

hopefully that all helps! happy to chat through any remaining ambiguity!


Just noting that this seems like a great sentence for scripting | monome/docs. It is mentioned as part of introducing SuperCollider in the studies, but could be helpful at a higher level.


Dan, this is tremendously helpful. Thank you!

Follow-up question: is it easy to interact with 2 Crows simultaneously? Can you connect both to a laptop and open two terminals to send them commands?

This is a point well taken. My recollection is part of my trouble with SC was that control code and engines had different syntax.

Follow-up question: how would you get 2 Norns to exchange information? Can they exchange MIDI? Is there another way?

60HP? How about 6HP? :laughing:

The smallest case I’ve seen is the 4ms Pod20, but I think it’s too shallow for Crow. They don’t seem to do a Pod20X unfortunately. Next smallest is Pod34X or the Doepfer beauty case (32HP). Any other suggestions?

This case is just for Crows, and possibly some format conversion and voltage processors.

I’m a norns + grid user, considering to buy a crow to start the eurorack path.
I don’t undertand a thing which seem really silly but here it goes:
When sending cv to one of crow’s inputs, how do i manage to use that signal into norns? Do i have to modify the script?
Would be amazing to have the opportunity to map a crow input to a norns parameter like with a midi controller


I just ordered a Norns Shield and have an odd question: With all the scripts that use Grids, how do people keep up with the different button layouts? I know the minimalist aesthetic is part of the charm. but having to commit the layout of every script to memory or needing to read documentation while using would get frustrating I imagine, especially with some of the really powerful ones. I have an idea for a possible solution but I’m curious how experienced users currently handle it.

1 Like

a script is an instrument. you practice a bit and then it gets easy. (or, i suppose, don’t practice and enjoy the confusion.) if you think there is a more intuitive layout you can always give it a tinker…


totally agree with z. this might be helpful though…


So folks either commit a layout to memory, reference back and forth to the online documentation, or just randomly press buttons? That seems so inelegant to me and possibly creates an unnecessary barrier to the adoption of workflows. There’s at least 30+ scripts that use Grids. I guess the upside is at least you can’t break anything by pressing the wrong button on a grid.

Here’s my big idea, let me know what you think:
I saw some photos of folks with notes underneath their Grids or they used a label maker. I also noticed how the documentation of a script usually contains screenshots from the Norns and a little graphic of the button layout. What if there was a standardized graphic of the button layout that could be printed out and placed on top of the Grid? Not something semi-permanent and gaudy like a Styleflip overlay with each button cutout, but something thin and non-intrusive that just surrounds the outside of the grid like a picture frame…call it ‘button layout frame’ or something.

The trick would be how to make it easy for the script authors to plug in the layout, like not only have a standard template, but perhaps some sort of web app where you enter the layout then it spits out the design file, or even a translator that looks at the script then automatically creates a frame of the button layout. Users could then print out the overlay however they wanted using whatever material they wanted. There could also be a option to print a smaller version of the frame that includes the buttons in the graphic, so if you didn’t want anything actually on your controller, you could print them on a 8.5x11 sheet and flip through the layouts like a patch book.


all right i took a short break. so… it sounds like an interesting project, to create and collect a visual representation of every grid layout anyone has come up with.

i guess it seems odd to me to frame this as a problem but that is ok

a design for an unobtrusive template frame would surely be a nice thing to share.


I’m all for chaos and “every script is a unique unicorn”, and gradually establishing a personal, intuitive and embodied relationship with things, such as software.

I was reminded by the grid overlay standard idea of three things: first these computer keyboard overlays which were standard with games (flight sims!) and office software too

Secondly i was reminded of the very cool, 8-stage paper tutorial teenage engineering OP-Z comes with

And finally the Teletype scene recall sheet by monome.

Maybe the above is inspiring? I dont have a grid, I love a good and funny and a bit strange=non-musical docs, and always try to doodle stuff in a little paper notebook (in the photo) instead about how things work and what ideas I’ve tried and what was fun and what I expect to need later and explain stuff to myself :memo:

PS I’ve daydreamed of something that would generate docs from code, for norns. Parameter names and value ranges i guess mostly, and current PMAPs. Paper is better though :wink:


For my own grid apps (not on norns), it’s mostly by memory when I’m using it. So far, most of my apps have been simple enough in scope and design that they can fit in my head while I’m using it. Or, if I forget how to use it, I can quickly be reminded with a reference card. My brain has gotten pretty good at grokking patterns in the grid and making mental maps of the various regions. But, like @zebra mentioned, it does take practice.

Here are a few reference cards I’ve made for myself for some of my apps.




I’ve yet to need more than a postcard to succinctly describe any of my Grid programs, but perhaps someday that will change. Trig, for instance, may get more opcodes someday and will probably need two postcards.


Thanks for the responses.

@zebra Apologies…I wasn’t trying to portray the non-labeled grid as a problem. The non-cluttered look is perhaps the most attractive thing about the Monome aesthetic. I was just offering a possible way to make scripts more accessible and easier to learn. Like a middle ground between the device looking cool and flying blind.

@PaulBatchelor Yeah, imagine if there was a standard way to display those layouts, instead of having to create a custom graphic for each script, you could just plug in the layout and note. Then the user could print out the graphic as a frame or strip that lines up with hardware…or just print out the graphic on a sheet of paper and collect all the different layouts like a patchbook. I think it would make things easier for the script author and the user.

@xmacex I guess my idea is similar but something a lot less obtrusive than that full OP-Z overlay. Perhaps instead of a square frame, a L shape. The question would be how to anchor it.

1 Like

I think the issue with a frame or an L is, how do you label buttons in the centre of the grid? A border label would only enable the labelling of buttons around the outside of the interface. How would one of these label Arcologoies for example? Or the multiple different pages of most ansible scripts?

1 Like

@nonverbalpoetry From what I can tell, in Arcologies the grid is just an open playing surface to input the sequence events. Aside from opening ports or copying the cells or whatever, most of the functions of the button press is set on Norns. There are no “this single button always does this” type assignments on that script, so there’s nothing to really label on the grid.

Looking at the Ansible stuff some of the multipage apps like Earthsea have functions in the middle of the grid that perhaps you would need a separate frame for each page, but I think just a frame or L for the main navigation would make it easier to get around.

Seems most scripts use either the buttons on the outside for functions/navigation, a x/y type row arrangement, or the grid is just an open playing surface, all which a frame or L could handle. I’m a complete noob so I may be wrong.

Does Crow has the ability to output gates ?