Teletype / Ansible: Button State inputs

I was just wondering how everyone else is using key inputs from Ansible for Teletype.

I just had an epiphany that I could use these inputs to momentarily change the behavior of the PARAM knob when held, basically allowing for 4 different knob controls in one. Now that I realize this I’m going to have to revisit a few of my recent creations to open up more knob inputs :smiley:

Was this the obvious use-case and it just took me a while to get it, or does anyone else have some creative uses?

(Oh shit – just realized the trigger ins could be used with Walk to open up even more modal control… this is exciting)

1 Like

I need to test this but I had thought that the keyboard key strokes could not be held down or gated in the same way the scene triggers can and so could only be used to sample the parameter input with each key press. Hope I’m wrong and you are right though!

Just to make sure we’re talking about the same thing, I was referring to the 2 buttons on Ansible, which get mapped to ‘STATE’ 11 and 12 - not keyboard input

Ah sorry my mistake I missed the ansible bit

1 Like

this is to say, you could use normal trigger inputs (STATE 1-8) and leave those scripts blank, and you basically have arbitrary inputs for polling digital values, like ansible


wait what? I had no idea bidirectional II is already a thing. I wonder how this could be used to send (converted) note number data from midi to teletype.

no ansible luck from EFN as of yet (someone on the eu border must be having fun with an array of arcs and ansibles). this has been a difficult month :sweat_smile:

I’m updating the title because I think I’m confusing people by saying “key” inputs haha

No bidirectional II yet, but the Ansible gives you two but Ansible gives you two buttons with momentary states (on/off) that can be read. As @tehn mentions, you could do this today without Ansible by just having a couple blank scripts that are attached to some sort of button (like Walk perhaps) but I like the idea of having them right near the knob they’ll be affecting in my patch, and not requiring any cables :slight_smile:

Hopefully I can update one of my scenes to shown you what I mean soon.

1 Like

Ah, my noob understanding was that this implies communication from the ansible to tt :slight_smile:
What tehn mentioned is TT internally. How is the state from ansible read then?

edit: I assume the difference being that in bi directional both could push messages.
still quite powerful and new, being able to fetch values from another module!

some confusion about nomenclature perhaps, let me attempt to clarify

i believe previous conversations about “bidirectional” referred to being able to both set parameters (which exists) and also get parameters (which only exists on ansible). so for the sake of that earlier thread, yes, teletype has bidirectional ii. the framework is in there to be extended in various ways.

what you/we may be getting at, however, is multi-master i2c. currently the ansible can’t initiate an ii transfer-- teletype can only query it for data. so, for example, we couldn’t have a key on ansible do something immediately to another module. i’m working with a few people to create a broader, flexible i2c scheme/protocol that would be ultimately flexible when completed.


maybe something completely different than what you want to create, anyway I managed to get bi-directional i2c going between aleph and an stm32, as I recall these were the changes on the avr32-side, feel free to use it if you want!

the stm32 side is here:

1 Like

Excellent. As the number of devices and firmwares increases it gets even more important that the protocol is forwards and backwards compatible.