Teletype ARC OPs


I integrated my diy arc clone into Teletype environment.
My original intention was to get a very fast euclidean pattern and tracker pattern controller (with optical feedback).
But the OPs can for sure be used also differently.

I am not sure it also work with the original ARC (I power my clone externally).
If it works with the original ARC maybe it is an option for the official firmware.To figure this out maybe an original ARC owner with HW and FW knowledge could collaborate a bit…


for a better discussion, can you describe what your arc ops do?


Excited to hear more! Would be cool if this stuff was possible:

Edit: OPs improvement

6 modes implemented.
Each ring can be set in a separate mode.
The Mode 0 is a bit special since it covers the Euclidean sequencer.
In this mode the TR outputs are internally connected to a ring.

Modes 1,2,3 are „only“ display/set value modes for any purpose.
You can set or get a ring value by SVAL or VAL. You can use it for any purpose in your scripts.
Display mode 1 is for Notes, mode 2 is for increasing values (means the ring lights will increase with VAL, and mode 3 for decreasing values.

Mode 4 and 5 are to configure the Euclidean pattern sequencer (length and phase).

Mode 0(Euclidean controller mode)
Mode 1(pitch display mode)
Mode 2(max Val display mode 0-64) - e.g. for slew rate, length or others
Mode 3(min Val display mode 0-64) - e.g. for Start of pattern or others
Mode 4(Euclidean Length configuration)
Mode 5(Euclidean Phase configuration)


ARC.MO x y

This will change function or display of the rings.
x - Ring (1-4), 0 for all
y - set mode (0 Euclidean,1 Pitch, 2 Max Val, 3 Min Val, 4 config length, 5 config phase)

ARC.VAL x - set/get current value of ring x

x - Ring (1-4), 0 for all
y - Ring value (0-64)

following OPs are especially for Mode 0 (Euclidean Mode)


reset/sync of all ring steps to 0


1 on - all rings are synced [default] ; in EUCL Mode to the slowest (longest) ring
0 off


x - Ring (1-4) , 0 for all
y - length of pattern [default 16]


x - Ring (1-4), 0 for all
y - step / phase offset

ARC.SCR x y - start a script at Euclidean trigger, only in Mode (0)

x - Ring (1-4), 0 for all
y - Script (1-8)


Get the current euclidean step value. Returns 0 or 1.
x - Ring (1-4)


Put a little demo of the euclidean mode on youtube, please dont blame me its my first one :wink:


Wow, this arc design is wild and radical!!


Following this!
I think it would be great to have arc ops!
That euclidean op looks great!
:clap: :clap:


Form follows function and the aluminum pcb panel was the easiest and cheapest solution for me; the small rig I had at hand.

I think about a laser cutting wood housing … when I need my small rig again for other purpose. Then the design get hopefully more elegant.

1 Like

that’s really nice. i hope this ARC OPs make it to the upcoming firmware release.


another option is to use the same op and use indexes 1-4 for rings and 0 for all rings.


Good hint, I will change this.

BTW: do you know if there is some design guideline for ports, scripts,… (0-3 vs. 1-4), I am not sure if this is consistent already today for Teletype OPs but maybe that’s another discussion :wink:

we don’t really have any guidelines other than the existing ops (maybe something we should consider at this point!), and unfortunately we don’t really have all ops behave in a consistent manner when it comes to being 0 based or 1 based. in this particular case, there are ops that treat 0 as a special value for “all”, which seems to be a good fit here.

btw you don’t need separate ops for getter/setter combo - you could make ARC.VAL work for both setting and getting a value.

one useful addition could be having different visualization styles, which could be a parameter for ARC.MO.


I am aware of the feasibility of the get/set OPs combination, my intention for SVAL was that when I used in a script for myself it was not clear on first sight if it’s a get or set, so I did it this way. But I think experienced TT users know about the potential double usage and I will change it, so thanks for this hint.

Regarding MO I am not 100% sure what you mean, main reason is already the change of display/visualization and control/config mode. I will add a video with a bit more melodic example next week to exemplify this better.

1 Like

While not yet fully understandig what these OPs are doing and how they work in the teletype context, I am looking forward to more ARC integration. :slight_smile:

I know it is a bit of a niche use case but it would be great if push button encoders would also be supported and encoder pushes can recognized.

1 Like

I had it first in, but removed it.
Main reasons:
1.with my ARC clone I sometimes activate it accidentally during performance
2. debouncing code need valuable timer resources
3. a small change in monome.c is necessary and I think this would lead a longer discussion with Then :wink: .

1 Like

i just gave this for a spin and it was really fun. :100: thanks for your work on this. behaves just as i’d expect it to. i didn’t dig too deep into euclidian stuff but when i saw your post that was the first thing i thought of doing


Do these ops take advantage of the nice visualizations of Arc ? Apologies, I’m not familiar with how Arc works, but I am interested in getting one if it can be used with Teletype. Too bad these didn’t get in the 4.0 firmware, would be interesting to try them out.

Not sure if customer need is big enough, to include it into the factory FW. I didnt push for that…
Keep in mind, Teletype only offers one USB interface with limited power supply capabilities.

Maybe someone has time to develop a USB to I2C interface module :wink: , this would make things easier.
Also for Grids.

My teletype scenes do not change very often and I normaly dont need to plug/unplug the keyboard/ARC. But you should be aware that if you want to change scripts “on the fly” it can get a bit tricky.

1 Like

usb to i2c module = ansible (host) or crow (device), yeah? :slight_smile: