I hope this is the correct Teletype thread to post this in — I can delete and repost elsewhere if this is not the case!

There are two things I’m curious about pursuing with the TT, but don’t know enough about the back end to know whether it’s even possible:

  1. Could there be some way of “mirroring” the Teletype display, via USB? I’m thinking here of a live-coding performance context, and how cool it would be to throw the interface up on a wall, but also in terms of accessibility — it’s a fairly small screen, and not always in the most visible / ergonomic position in our cases to be viewed easily. How great would it be to have a full-size duplicate of the interface running on, say, a laptop? Being able to mirror the screen would also be fantastic for tutorials and other educational applications!

  2. This might be more possible than #1: could someone conceivably write a program that would let you compose Teletype code on a laptop, and then “export” it to the module? I think something similar is happening with the ability to back up scenes via USB, but how about the other direction?

not sure this is something feasible - this would require creating a device that would sit in between teletype and a laptop that would mirror screen updates on teletype and send keyboard presses to teletype, which would also require modifying teletype code. the most realistic workaround is vcvrack version @Dewb is working on: WW+MP+ES in VCVRack

Could we have a SCENE.P op similar to SCENE.G that loads a scene without changing the pattern space?

2 Likes

For #2: You don’t need any special app to compose TT code on a computer. When the TT writes to the USB it writes files named ttNNs.txt (where N is a number from 0-9). When it reads from the USB it reads files named ttNN.txt. All these files can be edited using simple text editors (not word processors).

1 Like

Hi all, what’s the process to add new characters (or heck, draw pixels) to the teletype?

I see the 1bit turtle thread but not sure what the process is to add new characters.

Here’s my use-case: i’d like to have something like a visual icon for my different scenes. I guess alternatively, i could try my hand at minimal ASCII art.

For example, I like the graphics that folks have been adding to Norns libraries, and the graphics on the multi-effects Zoom MS-70CDR. They help me distinguish the different effects as i flip through quickly.

zoom multi-stomp

Oh, wow, I hadn’t realized that. Thank you so much!

TL/DR: that would involve changes to the teletype sources. below, i assume you can read the c code.

nothing like the norns graphics API is available on teletype.

it’s probably not realistic to expect to do much with bitmaps, but adding a few small glyphs like the turtle might be effective.


the drawing layer for libavr32 is much more low-level than on norns. (the processor is 100’s of times slower, it doesn’t run linux or any other OS, etc.) on norns we use cairo and have fonts and stuff; on libavr32 eveything is done from scratch.


characters

there is a single font; glyphs are hardcoded as column-first bitmaps
[ https://github.com/monome/libavr32/blob/main/src/font.c ]

there are also some ugly methods for rendering the same glyphs in larger sizes or with consistent glyph spacing. (doesn’t look good but maybe you need it.)

a properly fixed-width glyph set would be nice, but flash memory is another thing that is extremely limited on these systems. hopefully looking at that source makes it clear how the glyph data is laid out and what you would need to do to customize it.

if you are really actually wanting to do this, i can dig up the scripts i used to render arbitrary truetype fonts as bitmaps in this format when this stuff was first developed for aleph back when. (it is rough and i wouldn’t really recommend going down this rabbit hole.)


pixels

pixels and rectangles are easy.

the abstraction for a drawing surface is called a region, and all the drawing commands are here:
[ https://github.com/monome/libavr32/blob/main/src/region.h ]

a region is an arbitrarily-sized grid of pixels that can be composited onto the screen buffer. typically an application would statically allocate one or more regions for use as working buffers.

you can see examples of region drawing and management throughout the teletype sources, such as in line_editor.c etc

it is also straightforward to hardcode the contents of a region. for example, the hebrew glyph rendered at startup on aleph, looks like this
[ https://github.com/monome/aleph/blob/dev/avr32/src/startup_glyph.c ]

and rendering it just looks like this
[ https://github.com/monome/aleph/blob/dev/avr32/src/screen_startup.c#L18 ]

so if you want to just flip through a number of static bitmaps, i think that would be a fine approach.

to be clear: i don’t think it would be at all easy to add much graphics stuff to the teletype, mainly that flash memory is seriously tight. (and of course it’s not obvious how you would manage and control the presentation of graphics.) but you could get into this stuff for a custom application firmware.

6 Likes

there is a work-in-progress implementation of Teletype for VCV Rack. There is a pre-1.0 build up at that link. (latest build as of my posting date is from July 2020)

3 Likes

So often I find myself moving to the tracker to play with my patterns and it occurred to me that it’s akward to move over to the arrow keys for navigation - especially on this basic and stock teletype keyboard. The keys are awkwardly flat - (I do plan on getting another keyboard to replace it)

It would be nice if navigation was done with WASD - then your hands don’t have to move at all from the home row. We can’t enter Characters into the pattern fields so all the keys are available.

Would there be any conflicts to having the WASD keys navigate in patterns? They could even work along side the standard arrow keys.

Anybody else running the beta version and running into issues with Scene load? I only have 3-4 scenes and when I try to load an older one (re: from 4 to 3) I can’t back to loading any other scene other than 3.

Not sure what’s going on but it’s highly probable that it’s user error. Just wanted to verify. I’m using the keyboard to make the load.

Couple thoughts:

Was it a script transferred from computer? It is possible to “damage” scripts if the line endings get messed up.

Are you using escape to access the scene list? Because I have accidentally used the alt+escape combo instead several times.

It was scripted using the keyboard and I’m 100% certain I’m using ESC as I did it more than twice, as you can imagine. Even restarted the case just to make sure it isn’t a temporary thing. It’s persistent.

I’m ok with deleting the scene (is that possible?). It’s not important. But I’m rather worried that this might happen in the future, or with a more elaborate scene, and that would not be a good occurrence in a live setting.

Also curious why it’s happening.

I was bit by something similar a few days ago. This firmware has been sitting on my TT since October, never occurred before, only new thing was it happened just after adding JF to my i2c bus. In the end, it seemed it was a slight bend on the cable to the keyboard…

I’m sure it’s not a cable issue as it’s wirelessly connected to TT. I’d be inclined to believe it’s a software bug, but then again if nobody else is having any issues with Scene swapping then I somehow managed to bork it.

OK, cool. Funny that similar behavior struck us pretty much at the same time…

If possible, maybe try with a wired cable if it strikes back?

I’ve “deleted” scenes by saving a blank scene over the top of them, either via USB stick or the on-board TT save interface (which may not be available to you) by tabbing through with [ or ] before pressing ALT+ENTER.

Can you switch scenes using the SCENE X OP?

Proposing here a possible enhancement to add an op, possibly “PX” that can address the pattern data as a linear 0-255 (or possibly configurable) array to simplify when arbitrary dimensions are needed for a particular application, rather than 4x64 (or rather, in addition to the existing 4x64 capability).

This is a forward from the discussion segment that goes into more detail at:

1 Like

I started to get an issue with the teletype as mentioned here.

The problem: when you hit escape you’re prompted to switch scenes, if you hit alt+esc you’re prompted to save current scene. In both cases, the default suggestion from the teletype is the current scene, right? Ok, the problem is that “sometimes” my teletype starts to suggest a scene (both with save and switch scenes) that corresponds to the position of the PRM knob. Kind of as if it gets confused if I hit the small button on the panel and want to do keyboard-less loading.

It started after I added a JF to my i2c bus (tt + 2x txo + txi + JF + er301), and it only happens “sometimes”, usually after a while. I powered the case off and just waiting for everything to cool off, maybe it’s heat related.

Anyone had anything similar happen and found a solution?

That is very strange. In normal operation is there a threshold for PRM knob change that takes you from “suggest current scene” to “use knob position”? If so, you might have a noisy knob input.

EDIT: I don’t yet see where the knob value gets translated to preset selection in the code. preset_w_mode.c only shows [ and ] for switching presets…

Thanks! You got me on the right track!

I’m running a hacked firmware, and there was a problem in my code, everything is working perfectly now!!!

2 Likes