I will let @scanner_darkly weigh in on that decision. I made this primarily for myself to use with my Cirklon, and certainly don’t intend to step on the toes of what they are developing.
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
I think this makes a lot of sense. For the sake of my neurotic organization tendencies, I think I might swap the mappings of 1-32 and 33-64 for both SC.TR and SC.CV. This way I can keep the bank of 32 CCs together, and have the pitch and gates for the mono voices start at the same index number for both SC.TR and SC.CV.
I’m also open to changing the CCs that are used. I defaulted to ones that are undefined in the MIDI spec, but the way my converter is set up, there’s no other acknowledged MIDI activity on the channel that the 32 CCs are expected to come from, so it wouldn’t be the end of the world if they ended up just being CCs 0-31, or something like that.
I really like the idea that custom units could be shared and work with multiple MIDI to I2C solutions!
I also had the idea of having the map be editable. It could stored as a text file on the micro SD on the Teensy 3.6 that this will eventually be the target micro for this project. The map posted previously, with the changes addressed in this post, would be the default map.
I’m all for more unit types being implemented (easy for me to say, I don’t do the development for the 301 or the Teletype). I feel kind of bad having created a port map that uses all 100 of the SC.CV ports
I’ve never used the Cirklon USB port, so I can’t comment on that. Here is my preliminary panel drawing for the module. I’m really hoping I can keep it to 2hp! It’ll pass everything it receives on the USB Host port straight to the MIDI out 3.5mm jack, as I have the panel real estate, and that’s a functionality I feel is lacking in the realm of MIDI hardware. The toggles will switch between the Korg and Arturia “standards” of DIN to 3.5 adapters.
agreed having consistent numbers for
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).
I’ve never heard of webmidi. I’ll look into it. Thanks!!
This is all amazing - thank you!
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
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?
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.
I was having trouble coming up with reasons to break out the USB Micro to the panel of the module I’d like to make, but this kind of throws a wrench into me coming to the conclusion that it doesn’t really need to be there. Unfortunately there isn’t room for it.
What could be done though, since it sounds like the iPad (w/ USB Camera adapter, I’m assuming?) to Teensy combo is so straightforward, you could just wire up the Teensy GND, SCL, and SDA lines to a TRS jack with the pullups run from point-to-point on the Teensy board, then put some 1" heatshrink over the whole Teensy assembly so that you basically have an inline MIDI-to-I2C adapter. Then you could make a little 2hp panel the same way that @Burn did here with his 4ms Pod.
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 @Drillionaire - I love that it might be possible in 2hp!
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.
Thanks for all your input! This is all really valuable stuff to think about.
Totally agree. I think that I limited it to channel 16 for ease of implementation during development. With the configuration possibilities we’re now discussing, it makes more sense for CC channel assignment to be dynamic.
That sounds totally reasonable. I can’t say I’ve ever used it in any of my sequencing when I can just map CCs on the sequencer and the destination sound source.
This brings me back to thinking about NRPNs. I’m not sure how much hardware supports it, but maybe it’d be nice to be able to have more assignable ports with 16k values rather than 128. Maybe NRPN support is a moot point if it’s possible to have 16 channels of pitchbend messages that aren’t necessarily tied to a note # SC.CV port. I must admit, I wouldn’t be upset about not having to implement the previously mentioned scheme of scaling and all that.
I like the latter option. Something where if if you select four voices max for a poly group, the configuration page will let you know that from the starting port you select, 10 ports will be taken up (4 pitch, 4 velocity, 1 mod wheel, 1 aftertouch), and maybe not even the last two.
What this is making me rethink is how the poly ports would be grouped. If indeed it ends up being that they can be assigned at any starting port #, I think it would make sense for pitch, velocity, and MW/AT if they make the cut, to all be sequential, rather than grouping all the poly pitch, poly veloctiy, etc grouped together.
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.
That would remove a significant amount of the headache of configuration. Being able to set the channel in the unit preferences would streamline it even more.
Do you mean ER-301 units?