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:

3 Likes

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?

4 Likes

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

4 Likes

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?

3 Likes

Lemur is a great one. Been a long time since I’ve written any Lemurscript.

Another one that I think would be massive fun with the ER-301 is TC-DATA. In addition to all the controllers you’d expect like x/y coordinates, number of touches, it also has a bunch of less obvious ones like compass heading, camera brightness, touch size, Apple Pencil azimuth, elevation, force, speed.

I think pretty much anything you could possibly sense and measure with an iPad, TC-DATA can use it as a MIDI or OSC controller.

4 Likes

I would definitely like to use both @scanner_darkly and @anon17137829’s options. And I like the idea about some kind of shared mappings if it doesn’t mean less possibilities/customization.

Say you use a synth/module (in or out) that can’t customize midi CC’s which uses CC 0-13 standard mappings, such as modulation, expression etc…

Really cool with the mockup @anon17137829 - I love that it might be possible in 2hp!

1 Like

I’ve been giving this some thought, and will toss some ideas out for your consideration.

Mod Wheel is really just CC 1. On a keyboard (where the terminology is relevant), there’s only one mod wheel, and it’s difficult to use it with 10 patches at once. You could possibly eliminate these 10 slots, and just make CC 1 another CC you can configure, and set the channel for. Ideally it’d be great if you could set the channel for each CC rather than hard coding to CH16.

There are also 10 channels taken by aftertouch. I like aftertouch/channel pressure modulations on a keyboard because it’s really the only one aside from velocity you can use without removing one of your hands from the keys. That said, I don’t know if I use it enough to merit having it available on each channel. Could possibly just leave it on the 2 poly channels, and maybe 2 of the mono channels? That would eliminate 6 more for a total of 16 free SC.CV slots.

For what it’s worth, in my experience using the Shuttle Control, I like having pitch bend CV separated from the note pitch CV. That way you can set the ER-301 up to do things like pitch bend up 2 down 12 semitones at full displacement. Or you can remap it to something other than pitch - it’s one of the only standard MIDI controllers with resolution > 128.

Would also be neat to do this just by editing the configuration map - i.e. if the voices aren’t specified on the config map, don’t use them. Another way to free up SC.CVs for use by other devices (Teletype, 16n). I.e. if all you need is a 4 poly with velocity, don’t map voices 5-8 pitch & velo, and that frees up 8 SC.CVs. Not sure how crazy that makes the code. Alternatively, could specify max voices for the two polys in the configuration?

Anyway, just some ideas. :slight_smile:

2 Likes

as a side note, this is why i think maybe new dedicated units would be a better approach in a long run. so then instead of having to configure the firmware and the port number (okay, so knob 1 on my controller sends CC 72 which i mapped to SC.CV 35…) you could just add MIDI.CC unit and set it to 72.

4 Likes

Do you mean ER-301 units?

If someone (not me) draws up a specification for MIDI-over-i2c that incorporates input from users of various devices (*) then I will be more than happy to implement some units for it.

(*) A discussion on lines perhaps?

9 Likes

Wait… are you saying you will implement a MIDI interpreter on the ER-301 if the MIDI messages can be sent down the i2c cable?

Or have I misunderstood?

2 Likes

That’s what it looks like to you :wink:

From my point of view, I have an i2c stack already implemented, so it would be unnecessarily obstinate to refuse to add a couple more message types to it just because I have no love for MIDI.

Oh and I am a fan of @anon17137829’s initiative.

14 Likes

I share your view of MIDI, it was a friend for many years, simply because it was the only thing available, to me, at the time, but now I have other options I much prefer those :slight_smile:

Having said that, it seems that this is surprisingly low hanging fruit (an illusion created by the seemingly magical coding skills of @anon17137829 - I am still in a mild state of shock at how quickly this has come together) could be very useful and a ‘nice thing to have’, especially for me in the use cases I described above.

All that is to say, thank you very much for your consideration - very much appreciated :bowing_man:

3 Likes

:cry:

while these words hurt, I appreciate having a clear direction for the 301 :slight_smile: . For me, Mr. Drillionaire is doing a huuugely beneficial thing <3

4 Likes

Speaking for me personally, my collection of fine MIDI controllers doesn’t include anything that would be able to generate a custom NRPN message to send to the module.

I think this would be easier for me to remember. If I’m setting up voice 1 of a poly channel and know the pitch starts on 65, it’s probably easier to remember velo is on 66. Rather than, “hmm, I have this configured for 6 voices, so velo is on 65+6=71.”

Of course mod wheel doesn’t need to be per voice, and AT - well, guess it depends on if you’re planning to implement poly aftertouch or channel pressure. Poly AT would eat up ports pretty quickly, so unless you’re planning to make this really configurable I’d prob stick with channel pressure, at least for v1. Could always add more configurability and poly AT later? Just one opinion.

1 Like