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

Transit - MIDI to ER-301 via I2C [Development on Hold]

#101

With how loosely the Doepfer eurorack specifications are followed in the eurorack community, if I produced a module that didn’t follow the specs doepfer has provided to a T, I don’t think I’d be able to sleep at night :sweat_smile:

Yep, that’s the idea! Initially I just included it to use available panel space, but I think it will come in handy for possible customization in the future. I’m hoping that the robust design and small form factor both increase the appeal of this module to folks who might not have an ER-301. Maybe in the future I’ll offer I2C expanders similar to the TELEXi/o which will allow for configurable sets of MIDI to CV/Gate to be built up in people’s systems.
Actually, now that I think of it, with some slight firmware tweaks, this should be completely compatible with the TELEXo…

1 Like

#102

I’m not planning on a 1U version currently, but in the meantime, there’s this.
https://www.muffwiggler.com/forum/viewtopic.php?t=201396

1 Like

#103

No worries, if a 2hp 3u exists that’s already awesome :wink:

0 Likes

#104

re: i2c protocol, this should be a good starting point: https://github.com/scanner-darkly/teletype/wiki/II-protocol

but yeah, basically it’s address byte | command byte | optional parameters

it’s up to the device to interpret what comes after the address byte in whatever way it needs. instead of using one byte for commands you could use two, for instance, if you need more than 256 commands. same with parameters - each command can have as many parameters as it needs.

so i would just use whatever values are not used right now for the new midi commands and then for each define what parameters it needs. and since these commands will be for transit (and other devices that want to support this protocol) there is no need for any special consideration from teletype point of view (although it’s possible it’ll make sense to add support for these commands as teletype ops as well at some point in the future).

with that in mind there is a couple of things that should be considered when defining new commands:

the existing SC commands use the same command values as @bpcmusic’s telex modules. this makes it easier to re-use the same code in teletype (and to some extent, faderbank). so if there is a possibility that more telex commands will be supported by er-301 in the future you should try and use different values for the new midi commands to avoid possible conflicts.

i would also avoid 0xC0-0xFF range if possible as there are some vague plans to possibly use these in the future for global commands (commands that would affect all connected i2c devices) such as global clock / reset.

6 Likes

#105

This is all extremely helpful info, thank you!
Seems like the next step is to solidify the MIDI objects that we feel are most useful, pick associated command bytes for them, and get feedback from Brian on implementation.

Do you happen to know what the ‘SC’ stands for with the Telex commands? I’m wondering if they should be included in the MIDI unit nomenclature or not, e.g., SC.MIDI.Velocity versus MIDI Velocity.
Same goes for the periods separating words in the command names. They seem to be more of a Teletype formatting convention, and my inclination is that having the unit names be words separated by spaces, it might make them look nicer when looking through the list of units in the 301, and help distinguish MIDI from Teletype units, assuming that’s desirable.

1 Like

#106

Pretty sure it means Sound Computer.

0 Likes

#107

yep.

the naming for the existing SC.CV and SC.TR units makes sense as it’s easier to remember what they mean and what ops they’re mapped to (and they are under teletype units category). i don’t think new units need to follow this scheme as teletype support is not the primary use case. i’d just keep it simple MIDI ..

the dot is the teletype style (i2c and some other ops are grouped this way), i don’t think it’s needed here but then i’m not a heavy er-301 user so not sure what would make most sense.

one more thing to consider for these units: it’s possible eventually there will be more devices supported (nerdseq?). it might make sense instead of MIDI naming to use something more generic, like NOTE. this would require having a separate config though, to select midi channels etc.

1 Like

#108

That’s a good point about the NerdSeq. Maybe a “Voice” object would be the best way to incorporate multi-device compatibility. The unit could have a channel select option inside the unit context menu (where you’d load a sample, etc in a sample player), and then the only unit control would be a 3-option parameter, similar to the slew mode for the Slew Limiter, which would allow for the selection of gate, pitch, or velocity. Not sure if this would make things tricky in Scope view mode, or if it would be possible to have the unit name change in that context depending on which option is selected in the unit control.

Something I’m having trouble wrapping my head around is that, in removing the MIDI specific functionality of the units in order for possible future compatibility, I feel like this will shift configuration to the Transit, which makes sharing custom units trickier, and depending on user’s configurations of their Transit or XYZ future compatible module. Maybe I’m missing something and this actually increases usefulness of shared custom units/chains that use these more generic external input units we’re currently outlining.

1 Like

#109

Typically when I make a custom unit, I try to put all of the user controls and patch points at the top as custom controls, and then assign those controls to destinations inside the patch. E.g V/Oct, gate, env, velocity, etc.

That way when I look at it some months later, I can remember what I need to supply to the custom unit. When sharing I try to remember to unassign my sources on the top row. That way the patch becomes somewhat hardware agnostic. You can control the pitch, for example, with TT over i2c, or an external sequencer, or a S&H -> Scale Quantizer unit or other internal source, in the future a Note unit driven by Transit, or anything else.

2 Likes

#110

Maybe it would be a good idea to communicate with the NerdSeq developer?

I only mean to say that it might avoid duplication of effort, or worse two communication protocols being developed - oops!

3 Likes

#111

I’d be happy to hear any input that @XOR-Electronics has in terms of a standard that could support multiple devices!

0 Likes

#113

Hey! Thomas IS the developer, he’s around, he received an er-301and at some point i2c will be on he’s top to do list. I did reach him first to avoid any desapointment.
Hope I didn’t miss understood your comment Kel?
Yes, there’s already a thread involving the designer (Brian as well showed up, what an elegance!), thanks for pointing it Kel.

Cheers

1 Like

#114

Hey, i would love to give some input. But i still didn’t find time to check out the ER-301 itself…didn’t even power it on yet. (Yes shame on me…but there is too much priority stuff to do with the NerdSEQ at the moment). After i checked the ER-301 i can get a overview about what makes sense protocolwise.

As in terms of a standard…don’t overcomplicate things, but also don’t limit things to something which might be used in the future. Things can look different in a year, more gear supports it and then protocol limitations might be in the way (and implementations…not every project is maintained/updated so it might be tricky to change things in the future).

Sorry, i’m no help at the moment. But i will be soon as i intend to show a first implementation at Superbooth which is in about 9 weeks…

1 Like

#115

Thanks for taking the time to reply! I didn’t mean to rush you or anything, just wanted to tag you in this discussion so you’re aware of what’s being talked about.

Simple and open-ended/flexible definitely sounds like the way to go.

Hope all the NerdSeq development goes well! I had a chance to play with @skybox’s the other day, and it’s a really wonderful instrument! All the planned features he mentioned sound very exciting.

0 Likes

#116

Not at all, it’s okay, I just didn’t want this to be missed.

Looks like the connection has been made anyway - so all is good :slight_smile:

1 Like

#117

count me in!

1 Like

#118

Great! Thanks a lot.

0 Likes

#119

Managed to gloss over this - perfect :smiley:

1 Like

#120

PCBs, Jacks, and Teensys are here! The rest of the components should be here tomorrow. I’m excited to see how the backlit logo looks with a red LED :smiling_imp:

25 Likes

#121

I am so afraid I will miss a preorder. :smiley:

3 Likes