Adding I2C communication to open source digital modules

[jimi23]

Question for the tech crowd.
Bit of a far out idea I had having built most of the MI modules, and currently studying ARM embedded systems development. Would it be much of a leap to redesign one of their PCBs with an I2C header (easy) and add the required code for Teletype integration? (Hard)

One use could be to navigate the hidden modes/parameters and parasites stuff in the same way Just Friends works and have scene recall for it all.

Ive been going through the Telex expander code and the Teletype code itself to get a hold of the commands used. The newer MI modules (Warps, Rings, Elements, Clouds) all communicate with the Audio codec over I2C, so the pins are already setup.

I guess the thing im unsure about is adding extra stuff to the I2C bus that already has an audio codec and the (potentially huge) issues that might create. So far in my ARM studies i’ve only worked with 1 master, 1 slave on the bus so i’ve no idea how that would go! Im going to look at the hardware for Just Friends to see if it uses a codec on the I2C bus as well as external comm.

We’ve seen plenty of MI remixes, including the new ‘Supercell’ expanded clouds module. This would be a fun project if technically feasible. Just thought i’d throw out the idea so someone more knowledgeable could tell me its a terrible idea before I waste too much time tinkering

EDIT: I’ll have a play with Tides first I think. I2C is not used, but the default SCL SDA pins are used for one of the LEDs. I have a Tides pcb half built easy enough to run wires from resistor pads connected to these and have a go

[infovore]

Gut says: yeah, you really want to stay off the same I2C bus as the audio codec - because you don’t want all the audio codec data sloshing around the entire I2C bus. Is it definitely I2C, or I2S, that the audio codec is on?

Your other key thing will be ensuring any additions don’t interfere with timing. The basic pattern of the MI modules that do anything with audio - if I remember rightly, and bear in mind I’m paraphrasing - is putting data into a buffer so that the next time it’s read (ie, at the sample rate) it just plays out. As long as you can fill the buffer faster than the sample rate, you have no jitter or signal degradation. So the key is not to interfere with that. Writing that makes me think: something something interrupts; hopefully there will be some free ones left to play with.

[jlmitch5]

@jimi23 asked around and did some research on this a few months back. Take what I have to say technically with a grain of salt (I realized this project was over my head after doing this investigation)

The info I gathered is that you would want an unused i2c pair from the processor to break out into the pins for control. That’s how the ER-301 works. Unfortunately, like @infovore mentions, this isn’t possible as the available i2c lines are used for other things in the mutable modules. You could “hack into” the existing lines, but it’d be difficult to get good performance.

@sam proposed the idea of using a teensy to convert i2c messages into serial messages which can then be sent to the MI module’s existing serial I/o pins, with firmware tweaks to listen on those pins for the messages. What about: an audio mangling monome module

If such an intermediary “module” was created it might facilitate an easier path for i2cification of more MI modules to be controlled over i2c—I’d personally love to be able to change Rings’ modes with a teletype op.

[bezier]

My mind keeps coming back to the idea of hacking a eurotrash into a sample player with Teletype control. Free I2C ports are given on the teensy. Remotely selecting samples, loop points etc should be an amazing tool given the low hp and price point.