i2C to MIDI on Raspberry PI

[Nordseele]

@ParanormalPatroler

A few modules that support MIDI also have in/out MIDI as pins on the back (e.g. SDS_Digital Melisma, Bastl 1983 and others) , so being able to connect Hans to them would be ideal with no requirement for direct access to Hans externally. The fact that you have your design powered by the case, and act as a medium between things is just perfect, that’s why I’m so interested in this, all it lacks is the MIDI pins. If I’m understanding the core concept of Hans correctly, adding pins would be in the same spirit.

Yes, that’s right. I even hacked Hermod to add some Midi pins on the back haha. Nasty hack but it’s working…

Adding pins on the hat would also give the possibility to use an Expert Sleepers Midi breakout module for exposing DIN connectors.

I’ve looked more into it this morning, adding Midi in requires a small circuit, a few resistors and a 6N138 but this is done at the expense of the bluetooth quality.

@ParanormalPatroler

So in that sense it’s an either/or situation?

I think so, but this needs to be tested. The bluetooth on Pi Z and 3 uses the main UART, same one required for Midi In apparently. I’ll try to design a new revision including Midi pins and send it to the factory, we’ll see… It’s probably worth having both possibilities and I can see the advantage of having Midi pins on the hat, I should have added some in the first place.

@ParanormalPatroler

Ideally both, but either is absolutely fine. In a perfect world it would be possible to send MIDI Note information from the Melisma (which is a CV-to-MIDI chord module) and have the Teletype act accordingly, while also (and probably more importantly) being able to sequence the Melisma via CC using the Teletype. Being able to do just one of the two is also perfectly fine. The latest beta firmware for Melisma has more CC options than previously (e.g. chord list windows are CC controllable) which would allow full control via Teletype using i2c > MIDI), all I need is the translator!

OK, I understand. I think it “just” needs to be implemented in the code. Teletype has some new generic I2C ops, Hans could catch them on the fly (hans doesn’t have an address and dedicated ops) and trigger a Midi function + messages based on that perhaps ? This seems to be a bit complicated though. And as for Hans triggering anything on Teletype, correct me if I’m wrong @scanner_darkly but I’m afraid it’s not possible at the moment, it’s just not implemented in the code of Teletype; TT can read values on the bus and send commands but that’s it. The solution imo would be the following: Melisma sends a note or CC to Hans, Hans stores it in a variable and TT “reads” this object at a given rate (?) I think this was the solution suggested by scanner_darkly but I can’t find in which thread… (This project has been discussed in various places since june but doesn’t have a dedicated thread yet ^^)

@ParanormalPatroler

That’s just perfect! Being able to edit the MIDI map like that seems ideal to me. I’d love to beta test this and help as much as I possibly can.

Well, I will start by creating a new prototype with Midi IO and I will let you know once it’s ready

Oh and the Select Bus, I’ve heard about it but I’m not familiar with this protocol. Do you have any link/specs ?

[ParanormalPatroler]

@Nordseele

I think it “just” needs to be implemented in the code. Teletype has some new generic I2C ops, Hans could catch them on the fly (hans doesn’t have an address and dedicated ops) and trigger a Midi function + messages based on that perhaps ?

Sounds good to me. And the mapping is done via the custom JS midi map.

This seems to be a bit complicated though.

Complicated to implement you mean?

And as for Hans triggering anything on Teletype, correct me if I’m wrong @scanner_darkly but I’m afraid it’s not possible at the moment, it’s just not implemented in the code of Teletype; TT can read values on the bus and send commands but that’s it. The solution imo would be the following: Melisma sends a note or CC to Hans, Hans stores it in a variable and TT “reads” this object at a given rate (?) I think this was the solution suggested by scanner_darkly but I can’t find in which thread… (This project has been discussed in various places since june but doesn’t have a dedicated thread yet ^^)

Hmm, that actually sounds very reasonable. And variables would probably be the end goal here, although I think @scanner_darkly has been considering MIDI ops. But that’s another bridge to cross I think!

@Nordseele

Well, I will start by creating a new prototype with Midi IO and I will let you know once it’s ready

Right. Ready when you are! I’m very excited by the prospect. The 1983 shipment will have reached me by then so I’ll be able to test that module as well. It can act as a MIDI controllable quantizer which seems like a nice target for TT control.

Oh and the Select Bus, I’ve heard about it but I’m not familiar with this protocol. Do you have any link/specs ?

Yes, of course, it’s nothing other than MIDI messages actually.

MacroMachines/Eurorack-Preset-Protocol

and mainly https://docs.google.com/document/d/1YhPvAI6oliwLYSHhDholdAUym-TfBDGlxST-zDCP-qw/edit

[Nordseele]

@ParanormalPatroler

Yes, of course, it’s nothing other than MIDI messages actually.

Thanks for the links.
Well, ok I understand how it works now, it uses the CV Gate pins, Midi messages yes, but also a specific circuit…

@ParanormalPatroler

Complicated to implement you mean?

For the moment, I don’t know. But that’s a lot of Midi <=> i2c conversion when it could remain in the Midi domain perhaps.

@ParanormalPatroler

Right. Ready when you are!

Yeah, it will take a few weeks. The H.K post is not the fastest ^^

[ParanormalPatroler]

@Nordseele

And as for Hans triggering anything on Teletype, correct me if I’m wrong scanner_darkly but I’m afraid it’s not possible at the moment, it’s just not implemented in the code of Teletype; TT can read values on the bus and send commands but that’s it. The solution imo would be the following: Melisma sends a note or CC to Hans, Hans stores it in a variable and TT “reads” this object at a given rate (?) I think this was the solution suggested by scanner_darkly but I can’t find in which thread… (This project has been discussed in various places since june but doesn’t have a dedicated thread yet ^^)

By the way in case this is the thread you were talking about Teletype MIDI IN ops [experimental] there are, as of yet, experimental ops for MIDI In on the TT, but they are focused on the USB input in the front. But hey, it might work!

[desolationjones]

There is also a beta for Teletype follower mode, which causes it to trigger scripts based on a leader’s I2C messages. Conversations are still early but there is a chance of OPs dedicated to engaging/disengaging as bus leader/follower. These OPs make the most sense when all potential leader modules know how to yield the lead gracefully during runtime. Otherwise it’s very much a “set and forget” kind of config option.

[Nordseele]

About the MIDI electrical specs and the circuit needed on a RPI…

I did some research… So many optocouplers and variants of MIDI circuits haha… That was a good occasion to read the specs but I’m not certain of my circuit, even though I tried to follow the data sheet as closely as possible, and I can’t “breadboard” it right now as I don’t have the optocoupler here…

May I get the opinion of an electrical engineer or someone more experimented than me on the following circuit please ?

There’s not much space available on the Raspberry Pi Zero W add-on board so I tried to find the smallest SMD package possible for the optocoupler. Someone on MIDI.org was recommending a couple of them for 3V3. The cheapest and smallest, the TLP2361 is out of stock everywhere so I went with a Broadcom ACPL-M61L-000E which has a CMOS output and doesn’t need an additional pull-up resistor. (Really running out of space on the board).

---

Questions:

• Can you spot something weird or misconnected on this schematic ?
• Do you think I should use the 5V VCC instead of the 3V3 ? (I adapted the value of the resistors (R6 and R7) for the Midi out according to the 2014 MIDI specs
• Does it need anything else ?

---

N.B: I also had made another schematic based on the famous 6N137 but the component is a bit too large for my board, unless I put it on the bottom layer but I’d like to avoid that.
This one uses 5V. There’s also Lite On version accepting 3V3. For the anecdote, the Fairchild 6N137SMT has a power supply voltage of 4.5 V to 5.5 V but is used on M.I Yarns with 3V3. I’m a bit lost…

[okyeron]

I’m using the 6N138S on 2host with 3.3v. OOPS - it is getting 5v after all. That package is pretty huge, so I’d also like to find a smaller one.

(compared to that last schematic) My circuit is using a 470R from RX to 3.3v for pullup on pin 6. Pin 8 to 5V with a bypass cap.

FWIW - this post on the MI forum has some interesting tidbits of info - like differences between the 6N138 and 6N137.

EDIT #2 Why not just pull 5v off the Pi header and not worry about the 5v/3.3v issue?

[Nordseele]

Hey
Yeah the 6n138 and the 137 need a pull up resistor at the output but the small ACPL-M61 has a CMOS output and doesn’t need it, unlike the 6N138… Well, to be honest I grabbed info here and there but I couldn’t explain the difference between a Darlington and the other optocouplers
If I had more space on the board I’d use a 137 or 138 and the original Midi spec that’s for sure but yeah the package is a bit too large

Why not using the 5V line? Well, only because I’m not 100% sure of the safety of my 5V circuit. I’m powering the Pi via its 5V Gpio, I added a small protection but I’m afraid of damaging any MIDI device connected if the 5v input fails. Well, the 5v line is not directly connected to the midi out of course, but… The 3V3 reg by the pi seems less risky, honestly I don’t know Here’s my input circuit for info / The protection exists (I grabbed it from the RPI schematics, I’m just replicating the minimal protection of a Pi 3, right after its usb input) but it’s basic.

For the pull-up resistor used with a 137 or 138, I’ve seen many different values, from 10k (used in M.I modules) to 280r recommended in the old midi spec …

Oh and the data sheet of the ACPL shows a 15pf between the GND and the RX line and I have no idea if I should add this or not…

P.S: I should really get this book someday, it’s been on my wishlist for ages ^^

[okyeron]

FYI Some parts to look at

https://www.digikey.com/product-detail/en/isocom-components-2004-ltd/ICPL0601SMT-R/ICPL0601SMCT-ND/5037074

https://www.digikey.com/product-detail/en/on-semiconductor/HCPL0638R2/HCPL0638R2CT-ND/4744422

[Nordseele]

Thanks but these ones are also a bit too large I’m afraid (and the first one has a supply voltage of 7V), but I’m not sure this does even matter after all (cf Mutable instruments Yarns circuit)

I think I’m gonna try the ACPL which is just a rep of a 6N137 with a 3V3 voltage supply and less pins. If it doesn’t work it’ll be easy to change the resistors values and/or connect them to 5V. Apart from the baud rate the midi spec doesn’t seem to be too picky/limited after all. These chips all offer a 10MBps and MIDI only needs 31250bps, it should work unless I did a stupid mistake in the circuit.

Serial Midi IN was not a part of my original specs for the project, I don’t like the fact that it will probably ruin the Bluetooth Midi but it’s worth trying…

[desolationjones]

@Nordseele

Why not using the 5V line? Well, only because I’m not 100% sure of the safety of my 5V circuit. I’m powering the Pi via its 5V Gpio, I added a small protection but I’m afraid of damaging any MIDI device connected if the 5v input fails.

Your 5V protection is good enough! And those other MIDI devices should be optoisolated (though it’s not always the case). Is your 3.3V protection equivalent, with PTC polyfuse and TVS diode?

[Nordseele]

Thanks

I didn’t do the whole ideal diode / backpower protection ZVD circuit recommended for RaspberryPI hats. That’s why I was not sure of the safety, hopefully no one will plug both power inputs simultaneously.

The RPI Zero W doesn’t have any protection on its 5V input. But you’re right, my power input circuit (well, the polyfuse and diode) is a copy of the one used on a RPI3B+ so it should be enough.

The 3.3V is not equivalent no, the PI Z uses a PAM2306-336770 I believe it brings some protection too, but is it better ? I don’ know. Well, the other midi devices are supposed to be optoisolated, yes. I’ve seen MIDI schematics using 3V3 for the output and 5V for the input, sometimes 3V3 for both or 5V for both. That’s also why I was wondering which one is the best/recommended.

[Nordseele]

A couple of additional questions and thoughts, sorry for flooding this thread :-/

• The GPIO of a Raspberry are not 5V tolerant, if I use 5V for the optoisolator, this will damage the RX input of the Pi, right ? (Logic high output = Vdd according to the data sheet)

Update:
I think it should be good this time.
Supply voltage for the optocoupler is 3V3.
Supply voltage for the Schmitt trigger hex inverter is 5V (I guess ?) From what I read it’s acting as a logic level converter from 3v3 of the Pi to 5v, it’s sharpening and inverting the logic twice but I’m still unsure wether the supply voltage should be 3v3 or 5v.
From the doc it also might need an additional capacitor next to the vcc pin.
(And some ferrite on the RX and RX lines ? That’s from the MIdi specs)

I also added some Thru pins

Edit:
It turns out that “mini-uart” is not that bad after all.

I’ve moved Bluetooth to this UART on the Raspberry PI and I’m testing it with a Roli Block controlling an ER-301, I think it will be largely enough for Midi over Bluetooth. This means that both BLe MIDI and serial MIDI could be used at the same time.

This needs to be tested again once I receive the new boards with serial MIDI. Approx. 12 days from now

[ParanormalPatroler]

@Nordseele

I’ve moved Bluetooth to this UART on the Raspberry PI and I’m testing it with a Roli Block controlling an ER-301, I think it will be largely enough for Midi over Bluetooth. This means that both BLe MIDI and serial MIDI could be used at the same time.

This is absolutely great news. Any suggestions for Blue Tooth MIDI controllers that work?

I made time to do final modifications and now all I’m missing in that case is Hans

@konstantineffff

Not nearly as exciting as the actual design details, I know, but maybe incentivizing enough to know that you have one beta tester super ready and eager!

Quick question, am I right to assume that it’s possible to set the MIDI IN pin to merge incoming MIDI signals and send them to the MIDI OUT pin ?

[Nordseele]

Yes, the revision B of the boards is still stuck at customs in Germany.
Hopefully I will receive them this week. I also have to order the components for the MIDI circuit.

@ParanormalPatroler

Quick question, am I right to assume that it’s possible to set the MIDI IN pin to merge incoming MIDI signals and send them to the MIDI OUT ?

Well, like any midi interface you can connect only one device at a time on pins 4&5 of the midi header. But theoretically you can receive serial midi AND merge that with incoming BLE midi data and OSC data and send all that via I2c.

The circuit I added has midi in, midi out and midi thru. The Thru sends a copy of everything received on midi in to midi out by design.

These ports are exposed on a two rows header (same pinout found on the Intellijel 7u cases) Now, is it working ? we’ll find out soon…(I’m talking about the revB uh, the rev A without midi in works very well)

[ParanormalPatroler]

@Nordseele

Well, like any midi interface you can connect only one device at a time on pins 4&5 of the midi header. But theoretically you can receive serial midi AND merge that with incoming BLE midi data and OSC data and send all that via I2c.

The reason I’m asking is because based on what you posted before the most probable control scenario in my case would be Teletype > Hans > Melisma and that will occupy the only available MIDI input on the Melisma. I am hoping I’ll be able to repurpose the available MIDI IN pin on Hans as a merger of incoming MIDI data in order to plug the VCMC as an additional control for the Melisma. But it’s a very personal problem, I’ll find a workaround if that’s not an option.

Weirdly enough the VCMC has two outputs, a USB and a DIN, both at the front panel. I haven’t tried going VCMC > Teletype USB and use the MIDI IN ops yet, but it’s on my to-do list.

Things are getting complicated where I’m thinking of weird path ways like:

Teletype > Hans (i2c-to-MIDI translator) > Melisma
VCMC > Hans (merge incoming MIDI to the output) > Melisma
VCMC > Teletype (via USB)

There’s a feedback path right there, but I’m sure I can avoid it by selecting the appropriate channels. Thank you for the update! Super excited to see your progress.

[Nordseele]

This reminds me that I need to test the I2c input (I2c from Teletype). I spent too much time trying to connect a grid yesterday instead of doing that… I will try and report back and will think about your particular scenario/setup.

---

[Nordseele]

Teletype => i2c => Raspberry PI

A bit difficult to set up because the RPI is not meant to be an i2c follower [^1]

I’m using the Generic OPS and an address set on TT (IIA 51 Yes, 0x33 is the address of a 301, but this is only a test…)

These are the messages received by Hans, the Teletype is sending various messages like IISB3 4 1 2 12 and IISB2 4 1 2

A Pigpio wrapper for Node.js outputs these Byte arrays to the console…
From there, anything can be done, converting that to MIDI, triggering specific functions on the Pi, sending that over Wifi, passing that to another module etc.

---

TT messages received by the RPi and logged into the terminal. (Do not pay attention to the additional bytes, this is just a quick demo.)

---

Although it’s easy to modify the i2c (follower) address of the RPI, this is not something that can be done the fly (well theoretically it could but this is not recommended), therefore the Pi will “listen” to only one address at a time.

I have no idea yet if having three i2c busses on the same PI will affect the performances or not.
And this fake i2c follower/pass-thru [^1] is likely to affect the perf but perhaps not too much 🤷

[^1]: Learn more about the bsci2C function from Pigpio that makes a RPI act as a follower.

[^2]: Last but not least, the “i2c gpio” used for this system are not exposed on the latest revision of Hans but with a long stackable header, GPIO 18 and 19 will remain accessible, no additional circuitry needed.

[Broccoli]

that’s great but how do you manage MIDI inputs on 16n? I see only MIDI and i2c out.

[Nordseele]

That’s right the 16n doesn’t have serial MIDI input, it uses MIDI IN over USB