i2c-based ER-301 control via korg nanoKONTROL2
- norns (191230 or later)
- crow (1.0.2 or later)
- i2c-enabled er-301 (tested with v0.4.27-stable, probably will work with v0.3-stable, but not tested)
- nanoKONTROL2 (or other CC-sending fader/knob/button controller).
- The physical connections required are as followed: nk2 to norns via usb, norns to crow via usb, crow to er-301 via 3 or 6-pin i2c.
- To enable n16o, you can either run the n16o script, or add 2 lines to any other script’s init function, as defined in the main n16o.lua file.
- By default:
- cv ports 1-8 correspond to the nk2 faders (left to right), range is 0-10v.
- cv ports 9-16 correspond to the pan knobs (left to right), range is 0-10v.
- tr ports 1-8 correspond to R buttons (left to right). These are momentary, meaning the go high when they are pressed, and low when they are released.
- tr ports 9-16 correspond to M buttons (left to right). These are momentary.
- tr ports 17-24 correspond to S buttons (left to right). These are momentary.
- tr ports 25-35 correspond to transport buttons (all the buttons to the left of the fader). These are ordered left to right, bottom to top. In other words, the rewind button is 25, and the right arrow track button is 35. These are latching meaning they go high when pressed and stay high until they are pressed again. They will continually toggle states off and on with each press.
n16o is a norns script that turns a KORG nanoKONTROL2 into an i2c-enabled faderbank and button buffet (lol) for controlling an ER-301.
The norns script intercepts the midi messages from the nk2 and sends them as i2c commands to crow. Provided your crow and ER-301 are connected via an i2c cable, you can then use SC.CV and SC.TR devices on the ER-301 to listen for these messages.
I’m working to downsize my system, and will not have all the knobs of 3 Quadratts to control my ER-301 patches…which I tend to use a lot of! Since I don’t currently have a 16n, I wanted to be able to emulate similar functionality with the nk2 I had lying around.
Does this script work with other midi controllers?
Possibly not out of the box, but it could easily be edited to work with them…it’s just a matter of making sure the CC #'s each fader/knob/button sends corresponds to the correct ER-301 port this script maps it to.
For example, if you are trying to use this with 16n, you could set faders 1-8 to CC#'s 0-7 and faders 9-16 to CC#'s 16-23. See the image above for what the CC’s are set to for all buttons, faders and knobs on the nanoKONTROL2.
By default this scripts looks for what norns has configured to the first MIDI device, and listens on MIDI channel 1.
What are the default CC’s supported out of the box?
My nanoKONTROL2 is set to different CCs…how do I change the CC # each fader/knob sends to?
You can also set CCs of any non-nanoKONTROL2 controller to mimic those sent as the above screenshot shows (either fully or partially).
Instead of changing the CC values my controller sends, I’d rather change the script to accept a custom mapping of cc to cv/tr ports. Is that doable?
Definitely doable, but the code is written in a way that tries to map the nanoKONTROL2 very specifically in as few lines as possible…it’s gonna be a pain to try to get in there and tweak it as it is currently written. I could be up for adding new config parameters that allow you to pass tables or custom CC -> TR/CV port maps if it is needed.
This seems like a silly thing to tie up norns for…how do I use it in the background of another running script?
Yes, it’s a silly little utility. I tried to architect the code in a way that makes it super easy to run n16o in the background of any other script…you just import the lib and execute the init function (passing configuration params if you so desire). The main n16o.lua acts as documentation for how to do this, as well as all the possible params. This is really easy to do, you do not need to have any programming experience to do it. Happy to answer questions if they do arise though!
Does using n16o prevent me from using the controller for other users (such as mapping to parameters within a norns script)?
No, if you are running n16o in the background of another script, feel free to use the nanoKONTROL2 as you would and map any parameters using the midi-learn function…just be aware that if you also listen on a port that some fadder/knob/button is mapped to, it will effect both the 301 and the norns param.
Is this performant?
Maybe? It doesn’t seem to be causing any issues for me in practice, but note that currently I’m not throttling the number of i2c messages sent over the wire in any way (as during my tests, there hasn’t been any lagging even when I’m going really fast with the faders, trying to break it), but the throughput of messages does raise some concern. If anyone notices any performance issues, please let me know the scenario, and I will see if I need to implement any sort of debounce to lower the amount of messages sent.
The faders seem a bit steppy, especially at the lower values…is something wrong?
I’ve added 50ms of CV slew for the 16 ports the nk2 uses. In testing, this seems to fix the alias-y sound you get when moving the faders very slowly without introducing any sort of perception of lagginess. There seems to still be a distinct “on” value, for example, where you can hear a linear unipolar vca device go from “silent” to “not silent”. I’m not sure if this is a 301-thing or a thing with how my script works. Any additional bug reports or ideas of how to fix are greatly appreciated!
Can you make the nanoKONTROL2 (or other midi controller) button led states line up with the current state of the 301 device it’s mapped to?
No, I don’t think so…I don’t believe that norns supports bi-directional midi.