Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

Transit Module

Now being developed privately.


The main question to me is : would it handle polyphony ?
Monophony would have a very limited interest.

1 Like

This ^^

There are an awful lot of USB midi controllers in the world, being able to map them directly to i2c ports on ER-301 would be seriously good!

I am impressed with how quickly you have taken this from an idea to reality - excellent work!!


Can I suggest the inclusion of a diagram clearly showing how to wire this up for the Teensy novices amongst us?


I will echo @anon83620728 in saying this is most impressive @anon17137829!

I didn’t vote because I’m not sure any of the choices fit me.

I am interested in a direct MIDI solution for the 301. I’m not sure I’d want it to be i2c based though, due to the fact that I do use Teletype often, and wouldn’t want potential conflicts with multiple leaders in the ecosystem. I’m fairly sure that while multiple leaders can usually, sometimes work ok, there’s no actual code to handle it currently.

Ultimately I guess im hoping once the lower level SDK becomes available, something can be done with the UART, and dedicated MIDI Units can be made.

Not trying to discourage you though. Following with interest! It’s a cool project!


Yes, this too!!

To clarify my position:

I am really not interested at all in sequencing via midi; I have that covered - more than covered - in other ways with zero latency with CV.

I am very interested in revealing all the parameters in ER-301 patches to control surfaces where latency is much less of an issue.


I have been looking at making something similar, but i think i need help to make it happen. This seems cool though, would possibly be interested if there was a way of getting midi out of the 301 (i want to use the internal signals of the 301 to triggers visuals) :slight_smile:

1 Like

Very clear - thank you very much!!!


1 Like

Nice !
Out of curiosity, how is the voice allocation working ?

1 Like

Amazing work @anon17137829 - can’t believe you got this far so quick! I think all of this is really nice, and though I could use this as you are currently building i (using pitch, vel, modwheel, aftertouch to control other stuff than what they are supposed to), I would still very much like to see some way to use midi CC’s with ER-301 - for example as a possibility on ports 65-100. What do you think of that?


Sorry, yes I see - youre totally right.! Thats perfect.! :smiley:

1 Like

Great work! It’s really great to have the possibility to control the ER-301 with Midi via I2c. I have this 16n faderbank also running with a Teensy, the hardware is already there (I mean the jack i2c output) so I don’t know which solution i should choose, @scanner_darkly said he’s working on implementing midi to I2c for the faderbank. Anyway, both solutions will be fine and will be a game changer. Thanks again :pray:t2:


So basically all i need is to buy a teensy for $25/load up the free code, and hook up 3 wires and power and i have midi for the er-301 ?

well thats darn cool ! Thanks for sharing such a cool project !

I do hope to see a diy plan for 3.5mm midi at least : ) instead of having to mount the teensy so the usb port is exposed…

I wonder how solid the teensy usb port would be with a cirklon though…
I feel like i’ve heard the cirklon usb isnt very dependable, but please correct me if im wrong…

i think the more solutions the better, especially solutions that are easy for people to DIY! there is some overlap but they cover different use cases. using faderbank as midi to i2c will be useful for folks that already have one, but a dedicated module/device could provide other functions, such as being able to accept DIN MIDI, or having premapped support for various controllers.

re: mapping - should first 16 SC.CVs be reserved for faderbank? i think it would make for a better ecosystem if different implementations shared the same map (or some areas of the map). this way people could share their presets and create custom units that would work with either implementation. perhaps first 16 SC.CVs could be simply reserved as faderbank or MIDI CCs? this way you could use faderbank but later swap it for this converter and midi twister, or something.

another option could be introducing additional units for notes and CCs specifically. perhaps something like SC.NOTE that could produce either a CV or trigger based on where it’s placed?


Don’t worry, It’s awesome to have multiple options! I was just saying maybe I can use the hardware I already have (I need those faders haha), or I could also use your solution because the implementation looks very good and I can still re-route the faders through it with a midi hub. last week we had no midi to I2c solutions, now we have almost two, brilliant :wink:

1 Like

agreed having consistent numbers for SC.TR and SC.CV that represent a note makes sense, easier to remember.

re: text files for maps - one thing worth considering is using a web based interface to edit/upload maps (via webmidi).


This is all amazing - thank you!

1 Like

Oh my god, I was gone from the thread for a day and now this?

This module would be such a massive workflow enhancement for me. I’m interested in both the MIDI sequencing capability AND the USB Host, that one is huge for me.

Hats off, I would’ve never thought this would be realized this quickly. So you are building a module?

I’m going to have to look into teensy now :smiley:

1 Like

I just had another thought, I used to really like using an iPad for gestural control of synths - I am one of those folk who like the feel of the glass and consider it a new kind of instrument; the gyroscope can be quite good fun too!

I am pretty sure that the iPad acts as USB host, so I am guessing that with the current implementation that the iPad will ‘just work’ with a Teensy - is this right - or am I remembering wrong?

Lemur and ER-301 anyone?