i2C to MIDI on Raspberry PI

Nordseele · August 11, 2020, 7:11pm

I don’t know why DM don’t work but I think it’s fine if some questions are posted publicly too. I will post more details and a FAQ section asap on Github.

There seems to be a certain interest for Midi so I’m considering adding a midi header to the next PCB. The current prototype is made for Midi over Bluetooth

At the moment it’s mainly WIFI and Bluetooth

Actually, the “concept” is to have a RPI Zero W powered by the Eurorack case, attached inside it, connected to the i2c bus and accessible only wirelessly via Wifi (OSC) and Bluetooth (Midi).

Powering a Pi Zero W from the 5V rail is OK but it becomes complicated when USB are connected to it and draw additional current…

That being said, it’s already technically possible to connect a micro USB hub to its usb host input and connect a Midi controller via USB. I tested that with a Pi3, outside of the euro case and with an external power brick and it was working. But this is not something I’ve worked on much because my initial goal was to get rid of all the cable (USB, i2C etc) going in and out of the case. So… it’s possible but it’s not made for that.

I have to say that the “hat” is only here as an easy and rather safe way to power the Pi from the Euro case and to put pull-up resistors on the software i2c bus but things can be done and connected without the hat too. It’s just that it’s more risky.

No, not yet unfortunately. But this is something I have considered and I’m considering again now. At the moment there are no DIN midi connections (yet) on this small prototype hat. The original plan was OSC to I2C and Bluetooth Midi to I2C only. “Wired” midi has been added only three days ago while adding Ble midi, this explains why the hat doesn’t have any IO for that yet.

It should be “easy” to add a midi IO header and circuit in a future revision, Edit > but this would require using the UART pins of the PI and this would probably affect the bluetooth quality :-/

Right now, the Pi doesn’t talk to Teletype, TT is a leader, like the Pi and they cannot read values from each other [^1]: . Do you mean Melisma => Teletype or Teletype => Melisma ?
Teletype to Melisma should be possible but this part of the code has not been developed yet. But there’s a second i2c bus ready for Teletype, I didn’t have time to try passing values from one bus to another…

[^1]: Hans converts OSC and MIDI and sends that to ii followers only (TXO, 301, etc) via i2C. Midi to I2C is handled with a custom JS midi map that needs to be edited. There’s no “default” map.

github.com

nordseele/hans/blob/master/assets/midimap.js

// For Txo and er301: Port numbers starts from 0
// CC 
// Follow the structure of the object, you must return an array, even if a cc only returns one command.

const midimap = {

    cc: {
        
        112: value => ([
            { device: 'er301', unit_number: '1', command: 'cv', args: [0, value.mapped(0, 127, 0, 16383) - 774] }
        ]),
        
        113: value => ([
            { device: 'er301', unit_number: '1', command: 'cv', args: [1, value.mapped(0, 127, 0, 16383) - 774] }
        ]),
        
        114: value => ([
            { device: 'er301', unit_number: '1', command: 'cv', args: [2, value.mapped(0, 127, 0, 16383) - 774] }
        ]),

This file has been truncated. show original

ParanormalPatroler · August 12, 2020, 7:45am

It says that your profile is hidden and, to the best of my knowledge, this prohibits me from sending you a private message.

Yes please, consider me as a strong +1 for a MIDI header. Pins will do perfectly, no need for bulky DIN or over-complicating things, whatever is easier for you.

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. And even if there was a need for that a TRS jack would suffice.

The fact that you have your design power the RPI Zero W from the case, and act as a medium between things is absolutely perfect; that’s why I’m so interested in this, all it lacks is the MIDI pins and the code. If I’m understanding your original aim for Hans correctly, giving access to pins for MIDI in/out “behind the panel” would be in the exact same spirit, right?

No, not yet unfortunately. But this is something I have considered and I’m considering again now. At the moment there are no DIN midi connections (yet) on this small prototype hat. The original plan was OSC to I2C and Bluetooth Midi to I2C only. “Wired” midi has been added only three days ago while adding Ble midi, this explains why the hat doesn’t have any IO for that yet.

It should be easy to add a midi IO header and circuit in a future revision, most of the GPIO are free. The midi Input doesn’t need anything in particular but the output needs a 220 ohms resistor. This way, it would be easy to connect the Pi to the Midi IO of an Intellijel case, internally for example. Edit: not as easy as I thought, this would require using the UART pins of the PI and this would probably affect the bluetooth quality :-/

Does that mean it’s an either hardware MIDI or BLE situation?

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 repurpose it, while also (and probably more importantly) being able to sequence the Melisma via CC from the Teletype, without having to plug the two.

The latest beta firmware for the Melisma (not out yet) has more CC options than previously (e.g. Chord List windows are now fully CC controllable) which would allow almost full control via Teletype using i2c > MIDI, with no limitation over cable connections. All I’m missing is the translator!

Another thing that you might find interesting is that Melisma can act as a Select Bus master [1], which would also allow Teletype to control any Select-Bus-capable modules in a system that contains both.

The possibilities are endless!

That’s just perfect! Being able to edit the MIDI map like that seems ideal. I’d love to beta test this and help as much as I possibly can. I’ll also find a BLE MIDI controller to buy and test on top.

[1] In the video VCMC is sending CC messages directly to Melisma’s MIDI input, which is in turn controlling the Omnimod (screen on the upper left) and the WMD SSM (two modules, one on the top right and one on the bottom left) through the Select Bus.

Nordseele · August 12, 2020, 8:19am

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.

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.

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

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 · August 12, 2020, 9:25am

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

Complicated to implement you mean?

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!

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.

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

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

Nordseele · August 12, 2020, 12:22pm

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…

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.

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

ParanormalPatroler · August 12, 2020, 2:04pm

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 · August 12, 2020, 5:00pm

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 · August 13, 2020, 6:09pm

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 · August 13, 2020, 8:49pm

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 · August 13, 2020, 9:13pm

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 · August 13, 2020, 10:18pm

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 · August 13, 2020, 11:03pm

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 · August 14, 2020, 2:26am

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 · August 14, 2020, 10:30am

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 · August 14, 2020, 12:39pm

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 · August 31, 2020, 9:30am

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

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 · August 31, 2020, 10:01am

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.

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 · August 31, 2020, 10:22am

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 · August 31, 2020, 10:28am

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 · September 3, 2020, 4:52pm

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.