Hans Rev B

Hans Rev C

Github: GitHub - nordseele/hans: OSC and MIDI over i2c for Eurorack modules ER-301, TXo, etc. i2c to MIDI for Teletype, and more...

Hans - OSC, USB, MIDI, i2c hub


A Raspberry Pi, an add-on board and a bit of Rust forming a kind of i2c, MIDI, OSC hub / swiss knife. OSC to i2c, MIDI to I2c, I2c to MiDi etc. It talks to TXo, ER-301 etc, receives input from Max, Lemur, Roli Blocks, Serial MIDI, USB MIDI


Implemented and tested
  • OSC to I2C
  • MIDI to I2C
  • MIDI over Bluetooth
  • Serial Midi
  • I2c to Midi (Teletype)
  • Power (w/ protection) from the 5v rail of a Euro case


Still can’t seem to be able to DM you, so here’s my super enthusiastic post as usual! :grinning:

1 Like

All I get is “This user’s public profile is hidden.” and I have no idea how else to DM, but really I don’t have much to say other than that I’m super enthusiastic about this project, I’m eager to beta test whatever you send my way, I wish I could help with JS but unfortunately I can’t, but I can help with documentation, and that and beta testing the hell out of Teletype (the only i2c device I have) and MIDI devices is definitely on the table.

Also :partying_face: :partying_face: :partying_face: :partying_face:


Thanks :blush: writing some documentation will be hard task, I really appreciate your offer to help. The new revision of the PCB will add a header for a specific I2c bus for Hans (the Raspberry Pi) to act as a follower.

It’s been tested successfully but it is not a real pass-thru. Teletype will trigger some scripts on the RPi, or trigger some MIDI functions for example. All of this needs to be determined.

I double checked and my profile on Lines says that the users are allowed to contact me :man_shrugging:

Sounds fantastic. I honestly think you have a winner here. I’ve seen a few people express interest in i2c <> MIDI connectivity and a translator which a) gets power from the bus, b) can accept blue-tooth MIDI, c) can bring in contact so many things, will definitely garner interest.

Any chance that it would be possible (via the editor) to set the MIDI out pin to merge any incoming messages of the MIDI in pin with any MIDI messages created via the i2c > MIDI translation? I know it’s probably too early, but I’m dropping this here and we can revisit this again when the time comes.


1 Like

Yes it’s possible. That’s why it’s so hard to provide a description for this project, many things are possible. I’ll add that to the list. Right now I really need some help implementing all this, not because I can’t, but because of time and what takes a minute for a professional developper can take a bit longer for me.

it is possible to - interlink - all the inputs and outputs and protocols showed on the diagram. I implemented the basic stuff. What I needed for OSC and MIDI to I2c you know. I just put together the basic hardware and the work of other people who have created some node.js layers for MIDI, OSC, I2C and even PIGPIO (used for the I2c follower feature)

That being said, I2c to midi is not the simplest, the I2c follower thing is still experimental, it’s working but a raspberry pi is a Leader normally, that’s why we’re using a third bus for «I2c follower mode », well there’s a branch for that but you’ll need to send some I2c commands to Hans, you’ll have to use the generic II ops provided by Teletype and set a custom address. But technically it’s possible. It’s been tested already. It would need the same kind of midimap.js I’m using for midi to I2c.

On a side note, The code is not looking great at the moment, hmm that’s embarrassing :disappointed: but the concept exists , so does the hardware, it’s just a matter of putting all this together.


sounds super awesome!

1 Like

This sounds amazing, super excited to see the project released!

1 Like

That’s exactly what I expect.

  • You’d set up Hans’s Raspberry Pi to act as a follower, and use the third bus “i2c follower”.
  • You’d need to use the generic ops on Teletype which will be acting as a leader on i2c bus
  • You’d nee to use a mididmap.js to tell Hans how to handle the incoming i2c messages and how they ought to be mapped to MIDI messages at Hans’s MIDI output pin.

I am not familiar with the process of setting up a custom address but I’ll look into how that is done. I’ll also read up on i2c leader/follower set up, although I thought I understood the basics, I’m not sure I do since I didn’t know there is a need for different headers. Better refresh my memory!

I’m also curious, did you figure out if there’s indeed “conflict” between the serial MIDI connectivity and the BlueTooth one? If I recall correctly you mentioned that there might be some problems introduced if both are used at the same time, but that was an assumption before you received the second revision boards. Curious what the result was.

The third I2C header on Hans/RPI is actually an interface to the SPI/I2C Slave peripheral on the BCM chip. This peripheral allows the Pi to act as a hardware slave device on an I2C bus (cf bscXFER). This is not possible with the two other i2c busses exposed on Hans, they can’t switch from leader to follower.

bscXfer and bsci2c (bit banged i2c) are the only solutions I found to make the PI act as an i2c follower. And it was quite difficult to find a node layer for Pigpio implementing these two specific functions.

This is done in the init script of Teletype (see II Generic ops). The address chosen also needs to be set in a variable in the JS code.

Moving the bluetooth connection from the primary UART of the Pi to the secondary one is needed indeed in order to make the primary UART available for serial MIDI. This doesn’t seem to cause any conflict. This “slower” bluetooth is still fast enough to handle incoming MIDI.

1 Like

I have some moderate JS chops, am pretty comfortable with async/Promises, and might be able to help a bit. However, I’m not sure whether this is compatible with my i2c-speaking hardware (a crow and a W/) or how I’d go about hooking it up.

1 Like

Thanks @license

Hans is already compatible with Crow - and probably W/ and JF too - and should be able to communicate via ii with any follower. [1]

Some commands for Crow are already present in assets/commands.js but not tested yet. [2]

Those for W/ and JF were also present at some point but not owning these modules and therefore not having the ability to test, I removed them. It’s also important to mention that nothing is implemented yet to deal with a potential response received from “followers” modules. This is also why i removed the “getters” commands at that time but now I want to give it another try (will probably do that with Crow today).

What I did is very basic, it writes to the bus but it doesn’t read, though the i2c node.js module is very capable of doing that, in an asynchronous way etc.

This is on the “todo list”, but the actual code probably needs to be refactored before doing so, especially all the callback functions. I implemented things very quickly, sometimes copying and pasting from the docs of the Node modules used and the result is working but not clean. Anyway, I will test with Crow and report back.

[1] The fun fact is that there’s no need of the add-on board for that. Connecting three wires to the GPIO of any Raspberry PI, changing a line in settings.js and that’s it.

[2] I’m testing Hans with Crow right now. I can confirm that the connection via i2c is working, I’m sending OSC (i.e: /crow/1/output/1 $1) from Max and the RPI is connected to Crow. The voltage changes on output 1, as expected. (I’m glad it’s working actually, never tried that before) I will also try to get values from Crow.

Capture d’écran 2020-09-22 à 11.49.46


@Nordseele Just following up from the O|D thread, totally interested in picking one of these up to use with the ER-301 if/when it becomes available :slight_smile: Thanks!


I’ll post some infos/update first thing tomorrow morning :wink:


Very cool project, looking forward to this!

1 Like

Here’s a quick overview of the project in april 2021

The Hans “environment” is divided in two programs, one of them is coded in Rust and the other one in “C++”.

The main Hans_rust : Communication with the i2c follower modules like Er-301, TXo, Crow etc.

Hans_ii_midi : Teletype to MIDI conversion.

The project is still in development and should obviously not be considered as a stable solution or “ready for production”. Well, it’s not really a “plug and play” device at the moment.

If you want to help with the development / test I have a very limited amount of unpopulated boards of the rev C and of the rev A (no serial MIDI), but no components left at the moment… very simple smd build and short BOM

In some very specific cases, for testing purpose and if you’re already familiar with the RPI GPIO and can power the RPI with an external power brick, the add-on board will not be really needed. (i.e: Teletype to USB MIDI) but this needs to be done with extreme caution.

A: Hans_Rust (OSC, USB, DIN to i2c follower devices)

(I realize that I haven’t published an update since I moved the whole code to Rust. Well, there’s no Node.js anymore.)

Last time I checked, everything was working. OSC, serial MIDI and USB MIDI to ER-301 and even Ble Midi from Roli.

This “main” Hans is coded in Rust and is in theory fast and reliable. It receives OSC and MIDI and sends that to the ER-301 and TXo (etc.)

AFAIK, everything is ready for implementing other “i2c follower” modules than the 301 and the Txo. This would be great I think, idk.

The whole set of commands of Txo is implemented, even the experimental commands. Same for the 301. For OSC, I think that everything’s done. This was the primary goal of this project.

I have not worked on a generic MIDI mapping for the ER-301, but that’s the #1 priority. Right now it’s still CC n controls SC.CV n If you want to edit that, you’ll have to edit and compile the program. There’s no user friendly interface / system for mapping MIDI to i2c. The best would be to create a generic mapping distributed across 16 channels like the FH-1 scripts.

A word about Bluetooth: I only tried MIDI Ble input with some Roli Blocks, MacOS is likely to cause some problems - again - (see below).

B: Hans_ii_midi (Teletype to MIDI)

The TT to MIDI thing is not part of the “main” program. I wrote this small program in “newbie cpp”, I had to fork and edit Ttymidi to add beatclock functionalities so this part probably needs to be checked and improved by a C++ expert but right now, the TT to serial MIDI and USB MIDI is working. I don’t know how far we can push it but I’m sending MIDI CC and notes from TT at 25ms rate to an OP-1 via USB or to an ICMIDI4 via DIN and it’s stable. We tested that with @ParanormalPatroler

The Bluetooth MIDI output to MacOS and iOS though is not stable at all and it’s really complicated to troubleshoot/debug. There are multiple possible causes. Everything MIDI ble on RPI, Bluez Midi, MIDI ble on IOS is very poorly documented. I tried many things. I have no other Bluetooth MIDI devices than Mac/ipad here I can test with. I wish I could try the bluetooth output with some non-Apple device. I might order a Widi master for that but… We’ll see.

You may wonder why Teletype has its own program and is not coded in Rust like the “main” Hans. Briefly: the RPI 0 is not an i2c follower by design. This i2c follower thing for the BCM2835 is done with the Pigpio library, only partially ported to Rust so I used C/C++. That’s too bad, they’re not communicating each other, it would have been great to use the RPI as a bridge for merging multiple i2c busses. I briefly talked with the maintainer of RPPAL on github, some i2c follower functionalities in RPPAL may happen someday, without an ETA. Or, if you know how to port a C library to Rust, well… :wink:

Important: Using multiple masters on the same i2c bus, i.e Teletype and Hans both connected to the ER_301 or to TXo → not recommended, never tested.

N.B: Right now, Hans uses the Disting.EX MIDI ops (addr: 0x41, easily modified) and can also receive the generic II ops

C: The Hans add-on board for RPI

The “revision C” exposes three different i2c busses. One is for Teletype (the i2c follower thing), another one is the hardware i2c of the RPI (not used because it was causing issues with the ER-301, it works fine with TXo) and the last one is the one “Hans_Rust” uses, 2x GND, SCL, SDA. I haven’t had issues with this device, it’s powered from the 5V rail of the Euro case.

I created a small 3d printed case for the Raspi + add-on board, it’s recommended to have one for protecting the GPIO and attaching Hans in the Eurorack case.

There’s a “plan” to use another device than a Raspberry Pi in a near future but right now there’s no ETA . In more details, RPI has released its RP2040 micro in January, and Arduino has a device coming up, it uses the RP2040 and features both Bluetooth and Wifi. Smaller form factor than a RPI Zero, without things I don’t need like the HDMI output. Why not ? Well there’s no release date for this Arduino Nano Connect and it’s not even proven that Rust will run on it and that a dedicated IO crate will be created. I don’t want to redo the whole thing but I have two RPI Pico coming in the mail, I might try with these…

D: Installation of the software environment

It’s scripted, the install takes 15mn. Installing a headless RPI was a bit tedious before but thanks to the new RPI imager, there’s no need to create a WPA file or to “touch ssh” anymore. I need to clean up the readme but the install script lives here. For now, using this “Hans” project requires a bit of “agility” with Raspbian, a terminal, ssh, Rust etc. Hopefully this will improve.

N.B: Happy to share more infos and technical details about what is working, what is not working and why, etc → Feel free to post in this thread.


I’ve made a nice install script ^^


I’d like to get the opinion of the ER-301 users on the “MIDI to I2C side” of Hans.

Like I wrote yesterday, what’s preventing me from compiling and distributing a proper release of the Rust code and making “Hans” available to more users right now is that there’s no generic MIDI mapping made for the ER-301.

I don’t like the idea of a generic MIDI mapping but I also don’t like the idea that the end-user is gonna need to edit the Rust code, compile it again etc to do some changes to the MIDi map…

The best thing imo would be some “MIDI units” on the ER-301 side. Some small units like the SC.CV and SC.TR units with the possibility for each to set the channel, message type etc.

I could just convert the MIDI messages received on Hans to ii formatted messages received by the 301 and finish the Rust code.

I believe Brian suggested to create some MIDI units a few months ago (Just found this post from @EqualTemperament :wink: ). With the ER-301 being open source now maybe we could do that by ourselves now ? I’m not familiar with the code of the 301 but… At least, on the RPI side, this could be done very quickly.

What do you think ?


Hi @Nordseele just discovered this thread via your GitHub repo. Haven’t yet trawled the entire thread, but just to say I think this looks like a really cool project!

This may already have been covered, but I’d be really interested in attempting to make a narrow-format (4HP?) Euro module based on this project, if nobody has already taken that on.

My initial thought was that a 90-degree RPi GPIO pin-header would make this possible (at the expense of some increase in depth).

I’d want to break out DIN and/or TRS MIDI and USB sockets to the panel, and retain headers on the back for connection to modules supporting I2C.

Incidentally, I have a couple of DistingEXs, and would be happy to help test that, if that would help.

I also have some experience of web development, and would also be happy to help develop a web-based configuration tool, if that would be useful.

==== LATER ====

One thing that occurred to me: it might be worth adding a switch and a bi-colour LED to allow switching between WiFi hotspot mode and standard WiFi client modes.

This is what is implemented in the Seismic Industries Spink-O module to allow configuration of the WiFi client network settings.

In hotspot mode, the module runs a web server serving a form to enter network settings to join an existing network.

Connect to the hotspot on your phone etc., set the required WiFi settings, then click the button to switch modes and join the existing network.

1 Like

Thanks @toneburst

Well, I know there are some equivalent projects for Eurorack but afaik no one is working on a project based on RPI. With its HDMI port, micro USB power, CF connector, it’s not optimal for a small width euro module. My goal was to create a zero HP solution connecting to the IO of an Intellijel case or integrating in any DIY case while keeping the i2c cables hidden inside and the MIDI on the back of the case. And the USB cables, far away from the Eurorack case but the RPi having an aux USB port, I kept this as an option and integrated an USB-A in my recent “solo” case for the ER-301. This standalone case project actually serves as a demo and contains a Hans/RPi. For a little standalone box hidden in the case the form factor of the Pi doesn’t really matter. As mentioned before, I might switch to another board in a near future, I may share some files of the current board at this occasion. The schematics are no secret, they’re from the MIDI Association electrical specs and RPI schematics, the rest is just GPIO routed to 2.54 headers :wink:

Disting.EX integration:
In theory, everything’s ready for implementing its i2c functions and controlling it via OSC

The project used Dave Steele’s Comitup for Hotspot management. It’s currently removed from the environment but will be back soon. Comitup provides a simple web interface for entering the network details. With no known network around, it falls back to advertising a hotspot.

I simplified this dev board as much as possible. Hans, sitting inside the Eurorack case, is not easily accessible once installed so I didn’t add a button but only a main-purpose jumper. And the LED, well they’re on the Rapsberry Pi already.

Web interface:
It’s still on the roadmap :slight_smile: But there’s no real settings to edit at the moment. A web interface would be nice for editing a custom script etc for example.


FWIW, I’ve installed the ER-301 emulator/environment and I’m working on creating some MIDI units - mods - today. Well I’m “trying to create” these units is more accurate

Some early thoughts:

CC unit

Note unit (with the ability to select wether it’s a gate, pitch, on-off) Not sure what’s possible and optimal in terms of UX yet.

Midi channel selection for both units or 1 SC = 1 Midi channel ?

Beatclock unit, maybe ?

Way more complex than I had imagined… :pensive:

Edit 2 : This will take too much time. I’m not familiar enough with the ER-301 code, I keep getting errors in the emulator. Not going further with this.