#6

As an engineer myself, this thread makes me quite gleeful… even if it isn’t my project.

Love the collaboration. Keep it up :slight_smile:

1 Like
#7

First off, major thanks to @scanner_darkly for spearheading this. Super-necessary as things are getting confusing with the growth of devices on the bus. So great. :slight_smile:

I’ve taken a look at the proposed i2c file revisions and noted the following things:

  • We need to add in the range for the TELEX modules (0x60-0x6F).

  • Fix the conflict with the 16n (FADER) - the proposed address (0x60) is the same as the first TXo.

  • Fix the conflict with the ER-301 (colliding with Meadowphysics)

  • Add in the (tentative) addresses for a Tetrapad integration

How about these changes/additions?

// ER-301
#define ER301_1 0x31
#define ER301_2 0x32
#define ER301_3 0x33

// 16n
#define FADER 0x34

// Tetrapad (in-development)
#define TP_1 0x35
#define TP_2 0x36
#define TP_3 0x37

// TELEXo
#define TO 0x60
#define TO_0 0x60
#define TO_1 0x61
#define TO_2 0x62
#define TO_3 0x63
#define TO_4 0x64
#define TO_5 0x65
#define TO_6 0x66
#define TO_7 0x67

// TELEXi
#define TI 0x68
#define TI_0 0x68
#define TI_1 0x69
#define TI_2 0x6A
#define TI_3 0x6B
#define TI_4 0x6C
#define TI_5 0x6D
#define TI_6 0x6E
#define TI_7 0x6F

Thanks again!! :slight_smile:

3 Likes
#8

for er-301 i’m thinking it might be just easier to update meadowphysics (or just leave them be).

will include your changes! (i’ll expand the const names as shorter names might conflict with some existing defines).

1 Like
#9

Seems to me ER301 would be much easier to change as the module is still actively being developed.
Does anyone here know if OD is shipping i2c support in current modules? Looks like they’re sold out currently, but unclear if any units have even shipped with support yet (hence a much easier platform to update).

1 Like
#10

i was considering it in terms of communications required and potential confusion - it’d be easier to offer new versions of mp and tt at the same time than coordinating er-301 and teletype (or answering questions on why a particular version of er-301 doesn’t work with a particular version of tt). although since it’s all pretty new and we don’t even have an official tt release that supports er-301 maybe it’s not so bad (and there is a workaround since we already support 3 addresses for er-301). i’m good either way.

1 Like
#11

here is the proposal on universal (global) commands: Universal ops

i was also thinking of adding a feature to teletype where it would query all possible addresses and display the list of all the i2c devices that are currently connected. perhaps a shortcut in live screen? this would be super useful when you move modules around and want to make sure all your i2c connections are okay.

2 Likes
#12

I agree. ER is still an active beta and the users are used to periodically updating the OS via SD card. No need to force an update on Meadowphysics. :slight_smile:

#13

would you be able to coordinate er-301 update with brian? at this point i think i’ll just do one final beta which will have the new address, but can’t really say when it’ll be ready. worst case scenario i can create another beta for people who update their er-301.

#14

Sure - I’ll coordinate with Brian at Orthogonal. Let’s also coordinate on that beta as some things will need to change on the TT side to use any renamed defines.

1 Like
#15

do you mean faderbank? yeah we’ll need to figure out the sequence of updates.

edit: i think the best way to handle it would be to include the faderbank change in my currently open PR, merge that, i’ll update my tt branch to point to that, and then do a new PR for the er-301 change.

1 Like
#16

faderbank and ER-301 code would be trivially affected.

#17

i’ve added your changes to my PR, can you take a look when you get a chance? (once it’s merged i’ll do a PR for the er-301 change).

#18

Hi, sorry just a quick question about TT and Ansible via i2c … the first post mentions “ansible / midi”: Is it actually possible to send midi from Teletype via Ansible or is it only Midi to Teletype via Ansible ? Thanks.

#19

it’s to control some midi and arp parameters on ansible in midi mode from teletype. you can see available teletype ops here: https://monome.org/docs/modular/teletype/manual/#ansible

1 Like
#20

Ok, I see, thanks for your reply! maybe not I’m looking for but I will read the manual of Ansible :wink:

#21

somebody asked for a description of the protocol so i put together a wiki page: https://github.com/scanner-darkly/teletype/wiki/II-protocol

would be good to add a description of the hardware side of things if somebody wants to take that on!

4 Likes
#22

Thanks for doing this @scanner_darkly! Been meaning to throw some extension ideas at you, and talk more about the co-existence of multiple leaders on the bus. Soon!

7 Likes
#23

Is the Teletype hardware open source in any fashion? I don’t know that it needs to be for such standard things as I2C but I find myself curious about the hackability of the hardware…

#24

the hardware is not open source, but if you just want to hack something together to utilize i2c there are much simpler ways to do it. also take a look at @bpcmusic’s telex which is open source (both firmware and hardware).

1 Like
#25

Just learned that the forthcoming Sinfonion (monster quantizer) from ACL has an i2c port. Maybe some interesting potential there?

3 Likes