#22

just updating here in case someone comes across this thread. I managed to get PI4 working with ORCA and Hyperpixel4 screen using Elektron TM1 for midi output. Im using full ORCA linux version. atm for basic patches it is fine. Lagging a little bit once loading or injecting patches. I managed to crash only once zooming way out. Not stable once dealing with the top menu. Otherwise it works great. Will be testing it in more depth in the coming weeks.

fan4nsn895o31.jpg6000×4000

5 Likes
#23

So… what does the radiation trefoil key do?

1 Like
#24

loads empty patch wiping the whole screen :smiley:

1 Like
#25

this means that if I have a 16n, I can use it as a MIDI to I2C converter for ER-301 by loading the firmware you linked? Is that easy?
Thanks so much

1 Like
#26

Can one do this by not having 16n and just using Teesny instead, looks like this firmware @scanner_darkly is based on teensy that might be another approach? I am looking now to use a keyboard to send gates to ER301 via keypresses.

#27

@koshi it should be pretty straightforword, just grab a Teensy and follow the Transit schematics by Drillionare.

So do you confirm that 16n with the firmware linked above by @scanner_darkly can already work as MIDI to i2c converter?

Thanks

2 Likes
#28

His post reads as it can do it yes. I haven’t tried it as dont have 16n myself so cant confirm.

I think using Teensy might be easy approach here actually indeed! Thanks for pointing this out.
I wonder if I can power keyboard and Teensy connecting via i2c only? or would i need extra power source. Keyboard would be connected to Teensy via USB to send MIDI.

#29

yes, you can use 16n to convert MIDI to I2C. that version is pretty old though, so not sure it’ll still work, but you could check out the changes in my old branch to get an idea of how to mod the firmware: https://github.com/scanner-darkly/16n/tree/ttmidi2

2 Likes
#30

Are there any pull-up resistors on the I2c lines of a Teensy board ? I think you’ll have to create a small circuit if you wish to connect a Teensy directly to the 301. With a Faderbank though, as long as it is set to “leader” mode and has the pull up resistors soldered on (I tested that once with Scanner Darkly’s code), it will work.

Otherwise, for a Raspberry Pi, I’ve made this small circuit/PCB It’s made for OSC to I2c but it would be easy to add serial midi to I2c capability (via micro usb) I’ve planned to add Bluetooth Midi but it’s not done yet, I didn’t have time to do it. USB midi to I2c would be even easier. The other reason it’s not done yet is that I can’t decide on how to map midi data to sc.cv and sc.tr ^^

And for “I2c to midi”, the title of this post, it should be capable of doing that too, it’s just a matter of taking the time to code that, the “hardware“ is ready. Actually, I was just thinking of using Teletype for generating midi data, sending that over its i2c port, using Hans to convert that to Midi… well… loads of possibilities ^^

GitHub link: the repository is a mess, a mix of research notes and WIP, the OSC part, network mgmt etc is working but the midi part needs to be implemented. Any help and ideas appreciated by the way :wink:

4 Likes
#31

Thats awesome little board! Are you planning to make a group run of some sort?
Yeah i realise its just the time needed to code. I am using Preonic keyboard with i2c output via QWIIC connection, so potentially I can connect direct to ER301 “just” need to convert the code to firmware its useing. Which is here.
https://beta.docs.qmk.fm/developing-qmk/c-development/hardware_drivers/i2c_driver

Actually OSC is fine I am using MIDI from my old habbits :wink: idea is to use either Max or ORCA to send sequences / gates in whatever way to get to ER301. Atm I can do it using Motu Ultralite soundcards DC coupled outputs but its a bit convoluted way.

2 Likes
#32

Oh, I was not aware or this QMK project, but looking at the GitHub briefly, it seems to be very interesting! I will look into it more deeply tomorrow.

Communicating over I2c is not very complicated in terms of code after all and this QMK solution is probably already ready for that, unless it needs some extra pull up resistors once again. I was a total newbie 8 weeks ago and managed to “talk” to the 301 thanks to the Monome ii protocol over I2c but there are a few pitfalls with the 301 specifically (mentioned in my “research notes“ on GitHub and in another thread on this forum where I received many helpful comments)

Regarding the “Hans uHat“, it is still a kind of prototype and the project is very experimental but the OSC part of the project is already working (with 301, TXo and probably some other modules too, I have implemented the commands but I don’t own Just Friends etc, I cannot test that) that being said, I have 9 extra PCBs in stock If you’re feeling adventurous :slight_smile: I’d be glad to dispatch them for a very cheap price to make the development of this project move forward. Beta testers and JS experts wanted :slight_smile: Well there are only 5 SMD components on it, not a big risk.

I had to create this small PCB only because the 301 was not behaving correctly with the regular I2c lines of the raspberry Pi. While I was at it, I added a power connector (and basic protection) to power it directly from a Eurorack case (5v rail only). I also exposed the regular I2c lines of a Pi on top of a Software I2c gpio and custom pull up resistors (for the 301). The whole thing is very basic but it opens up a lot of possibilities. Two distinct I2c busses, WiFi, Bluetooth, USB… With a 15€ Raspberry Pi Zero W.

The “code” is just JavaScript, Node.js it should be easily customizable, the Midi feature will arrive soon, like I said I’m still thinking of the best way to map it, the best way is probably to give the end user the ability to bind CC and Notes to SC.TR and SC.CV in a JSon file… OSC on another hand just follows the commands already implemented I.e: /er301/1/cv/1 1234

image

3 Likes
#33

For info (about the project mentioned above), I’ve made some progress and implemented the Midi functionality today. It was faster than expected.

Support for Bluetooth midi devices but also USB connected devices. The midi devices auto-connect to Hans. (Ble midi devices have to be paired manually via command line, but it’s only needed once)

Each type of midi message and any Cc or note number can be binded to any ii command, any ii module and also modified through a custom function (for each), or simply ignored. Everything is quite easily editable in a separate JS “module“. At least it’s modular and I believe it will be quite powerful.
I’ve updated the GitHub readme if you want more info.

Edit: lo-fi demo of the wireless midi To i2c feature. https://www.instagram.com/p/CDrdIJWqsgr/?igshid=15149jq60alky

5 Likes
#34

This sounds really cool. I will PM you happy to beta test this.
I made fun discovery the other day as realised that Qubit Nebulae that I have has USB input and while it doesn’t recognise keyboard (I think its due to specific OS implementation there) I can switch MIDI interface on in pd so have been testing alternative instrument using the keyboard in PD and its heaps of fun! Also, was checking use of Faderfox EC4 which also worked. Actually I managed to power both with USB hub connected. Used EC4 as voltage meter and keyboard for triggering samples.


Wonder if there is a way of connecting Nebulae to ER301 then could speak to it over PD! :slight_smile:
#35

I’m extremely interested in testing this as I’m trying to get the Melisma to talk to Teletype and this is 100% what I need. We even added more CC control over Melisma’s parameters in order to open things up even more. I can’t seem to be able to PM you but I’m very keen to test this. How can we make this happen?

Is this USB or Bluetooth only? No pins for MIDI on Hans, right?

#36

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 :wink:

At the moment it’s mainly WIFI and Bluetooth :slight_smile:

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.

1 Like
#37

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?

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! :star_struck:

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.

#38

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 (?) :thinking: 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 :wink:

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

#39

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

2 Likes
#40

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

1 Like
#42

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!