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…
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 ^^