a thread to discuss adding generic i2c teletype ops for interacting with other devices.
background: the ecosystem of devices that can be integrated with teletype via i2c continues to grow with ADDAC221 being the latest addition. for each supported device there is a set of device specific ops (
JF etc). this makes sense for things that are indeed device specific (such as
it might however make more sense to create a set of device agnostic ops for things that are supported by more than one device. in particular, it might be helpful to have ops for:
- reading CVs (supported by TXi, ansible, ADDAC221)
- outputting CVs (TXo, ansible, ER-301)
- reading controller values (TXi, 16n faderbank)
- reading MIDI CC values (faderbank, ADDAC221)
- sending MIDI notes and CCs (faderbank, ADDAC221)
(note: the last 2 are currently not officially supported, 221 is still a work in progress, faderbank MIDI ops are available as an experimental build)
(note2: it doesn’t have to be for i2c only, in theory we could connect controllers or MIDI interfaces to teletype via USB, however i wasn’t able to make it work).
having a set of generic ops would provide several benefits:
- make sharing and re-using scripts easier
- make scripts more readable
- make it easier to add support for new devices
how could this work? let’s say we have a generic op to output a CV.
do what teletype does for ansible in tt expander mode: the same op
CV is used, and to output to ansible you simply use a different output number (1-4 will use teletype’s own outputs, 5-8 will output to ansible, and so on). pros: being able to easily use this in a loop. cons: you have to remember which numbers map to which device.
introduce a new op, say
GCV (“generic CV” - could likely have a better name!), which would have an additional parameter for the device number. the downside is that it’s more verbose.
for either option we would need a way to map output range (for option #1) or device number (for option #2) to actual devices. this would require a separate op, something like
CV.MAP 100 120 4 (map output range 100-120 to device 4) pr
CV.MAP 1 3 (map device #1 to device 3).
instead of using device numbers for mapping we could probably even map to the actual i2c addresses (i think this is what crow does too?). this would mean more devices could be supported in the future without having to create a new version of teletype firmware.