teletype firmware modified to run on ansible
this is teletype firmare modded to run on ansible. this idea has been floating for some years now and after a push from @desolationjones i finally decided to try it. there are some differences compared to running it on teletype, of course. here is the detailed breakdown:
you get 4 trigger and 4 CV outputs, same as on teletype
it will work as an i2c leader but you will need something to provide power and pull-ups for the i2c bus
you can still use
IN (will default to 0) and
PARAM (will default to
without display, grid is highly recommended - grid control mode will allow you to execute/mute scripts, edit patterns, load and save presets. press the main module button to enter.
you can upload scripts via USB stick. unlike teletype, it will load files named
tt##s.txt and save to
tt##a.txt - this way you can edit scenes on teletype, then transfer them to ansible without having to rename the files. white LED will be lit while it’s working with USB.
when the metro script is running, the orange LED will blink. you can clock the metro script externally by connecting a trigger to input 1 - this disables the internal clock.
most keyboard shortcuts are disabled but you can still trigger/mute scripts.
grid highly recommended
use USB stick to load scenes (it will load scenes named
tt##s.txt so that you can edit scenes on teletype, then save to USB stick and transfer to satellite without renaming files). while LED will be lit while reading/writing USB stick.
use input 1 to trigger metro script (internal metro clock is disabled when input 1 is used)
key buttons will trigger scripts 1 and 2
input 2 will trigger script 3
long press on mode button saves scene (white LED will blink to confirm)
mode + key 1 will load previous scene
mode + key 2 will load next scene
see teletype manual
also make sure to check the grid control mode
updating firmware will erase your presets
satellite.hex (521.7 KB)
satellite.zip (149.6 KB)
this version includes everything from the official beta posted here
this thread: > teletype: grid # code exchange and this page: https://github.com/scanner-darkly/teletype/wiki/CODE-EXCHANGE are worth taking a look for scripts that would work well for this.
wow wow wow 20 chars of exciment!
Oh man this is a game changer – I might need to buy another Ansible!
wow this is so cool. i can make my own ansible apps now
thank you so much for putting in the work. can’t wait to try this out.
assuming that this shouldn’t share the same i2c bus as teletype - yeah?
you can definitely have both on the same i2c bus as long as you don’t have multiple leaders using the bus at the same time (and even then it might just work in some cases).
Trigger 1 as a metro override is making more sense to me now. There’s value in having that method common to all Satellite scripts. I thought Ansible hardware didn’t have cable detection, though, so how does it decide when to switch between internal and external clock?
FWIW I think tying trigger input 2 and keys 1 & 2 to script calls would really open things up for the gridless. Not that there are many gridless Ansible owners, but perhaps they are employing their grids elsewhere!
And speaking of the gridless, will there be a non-grid mode method for loading scenes? I was thinking Mode key could do next scene on short press, previous scene on long press.
or Mode + Key 1 (prev) / Mode + Key 2 (next)
it does have detection on input 1.
yeah, this makes sense. and a long press on mode to save the current scene.
Cool – so triggering metro doesn’t actually have to happen at regular intervals in that case? Could I hook up a Walk trigger to input 1 and it won’t do anything until I send a trigger? Or will it be more like a tap-tempo kind of situation?
yeah, you can do that. i thought about implementing tap tempo for metro, but it’s something that you could just code as part of a scene.
what if the inputs we’re configurable? so that something like…
sat.in 1 $3
in your TT script, would use in 1 to trig script 3 of the loaded scene.
that’s definitely an option. another option is adding a grid interface to map keys/inputs to scripts. not sure it’s something i would add though - trying to keep this simple, and i see satellite being something you would specifically write scenes for, so you could just make sure that anything that needs to be triggered is located in scripts 1-3. another point to consider - without a screen, it’s much more difficult to figure out what’s going on, so flexibility can come at a cost of having to check for more potential issues.
attempting to flash my Ansible on mac with the update_firmware_command file returned an access error.
I’m on the admin login and get info shows full read & write access. this file is simply a shortcut for a terminal command, yes?
sorry, I’ve never had this issue flashing an Ansible firmware, whether ‘factory’ or OH.
open terminal, navigate to location, type
chmod +x update_firmware.command
thanks, I didn’t have an opportunity to test this as I stumbled upon the cause of my issue: terminal did not like the brackets in my pathname
thinking about using this to connect midi ops to er-301. for direct ansible “leader mode” control over 301 do i need a powered busboard/pull-ups or should it be good to go?
You need something with pullups, to my knowledge neither device has the hardware. Note however that the Just Friends v4.0 firmware enabled its (weak) pullups so if you are also using JF this may be sufficient.
ah ok. thanks for clarifying.