#266

agreed, I’ll be surprised if things don’t become at least a little shaky at high speeds. I’ll be testing it out more over the next few days.

Also, the code in that branch could probably be made slightly more efficient by doing the role-switching in the OPs – as it is now, read ops like TI.IN switch the TT from follower to leader and back twice, once to send the query and once to read the result, which is probably wasteful (better to lead-query-read-follow than to lead-query-follow-lead-read-follow). I was just happy that the simplest possible implementation worked at all.

1 Like
#267

yeah, this is definitely not working well in practice, but the problem doesn’t manifest itself in quite the way I expected.

Crow can trigger scripts rapidly while TI.PRMs work in Live mode, but as soon as a script is triggered that contains a TI.PRM OP, that OP returns 0 and Teletype apparently ceases to even try to lead (all future TI.PRMs return 0 until I power cycle). But it’s still able to follow messages from Crow, and Crow is able to send & receive to/from TXi – that’s the surprising part, I expected maybe the whole bus might freeze, or one of the modules would stop responding completely, but that’s not what happens.

I poked around a bit and found an article about problems using multiple “master” AVR units – the problem as described there doesn’t really match what I’m seeing, but I wonder if the cause might be related. Will continue to experiment.

Update: I got a version of this working last night (10/24), and it’s been working well today too. Heck yeah.

The important changes to my branches of teletype and libavr32 are:

  • Added a new I2C/TWI interrupt handler, different from the ones in the Atmel ASF code. It’s basically both the “master” and “slave” handlers rolled into one, but it’s also designed to pay closer attention to the TXCOMP bit in the TWI status register. That takes care of the issue I described above: TT was refusing to follow because once an attempted read/write failed due to the bus being busy, twi_busy would remain set to true, which would block all future attempts to read/write to the bus, even though TT could continue to respond to incoming messages from Crow. Adding a whole new interrupt handler is probably overkill for this; if it’s okay to make edits to the ASF code (and I see it’s been done before, in order to make it possible for I2C reads/writes to time out), then that problem can probably be fixed with a lot less code.
  • In addition to checking TXCOMP before switching between leader & follower roles, the new code tries to check whether either the SDA or SCL lines are low, and watches for the ARBLST status register bit going high. Both are further indications that the bus is busy, but so far I haven’t seen either of those conditions actually happen while TXCOMP was high, so monitoring TXCOMP alone may be sufficient.
  • Instead of running scripts immediately when I2C messages are received, TT now adds II events to the main event queue, and scripts triggered over I2C are run from the event loop.

Using this code I’ve been able to trigger four TT scripts (containing TXi reads) from Crow roughly every 100ms, while running a metro script at 20ms that also reads from TXi, so it seems to be doing the job!

Happy to provide binaries to anyone who’s interested in testing, and I also welcome critique of the code or ideas about where it should go (should it sit alongside the existing i2c code in libavr32 like it does now, or replace some of it, or just live in the TT codebase, or…?) if it were to be merged in.

4 Likes
#268

That seems like a big step towards a stable implementation of dual leader/follower! Do you foresee any stability gains for normal operations, or naive multi-leader configs?

#269

I’d be surprised if it made a difference for users with a single Teletype as the only leader on the bus, but for users with both TT and Crow, it might reduce the likelihood of TT stepping on Crow’s toes by trying to send a message to a follower while Crow is in the process of sending a different message. I’m not sure if that’s a situation anyone’s actually encountered, though – the TWI hardware may already handle that case well enough that it doesn’t really need to be handled in software (as long as the software gives up if it can’t access the TWI, which the current release does).

That said, the extra monitoring of the I2C lines and I2C-related interrupts may make it possible to add another status indicator icon to Live mode, showing when TT is sending or receiving over I2C or when the bus is being used by someone else, and I can see that being useful sometimes even in simple I2C setups. I can take a stab at that if it sounds appealing.

Are there any currently known I2C bugs/instabilities in TT? I’ve read a bunch of the Teletype Firmware i2c Debugging thread but it seemed like all the issues covered there had been resolved.

2 Likes
#270

i’m not aware of any issues other than the issues caused by unstable i2c bus or having multiple leaders.

#271

I’d really love to see a TT command to poll the CV values of ansible while running Poly Earthsea. The functionality already exists for both Meadowphysics and Kria, has some really fun implications re polyphonic live-playing into TT, and is hopefully a trivial addition (although I can’t know that).

To be clear: looking for:

ES.CV 1

etc.

for why?!

My thought is to store octave and note values in TT by playing Earthsea and cycle them against each other a la Kria while continuing to add new notes by playing them directly – hence chromatic Kria – or multi-looper Earthsea – is born. Manage pattern loop length via variables, switch which outputs are sending which data to which CV outs and in what combinations, decouple / shuffle trigs between patterns, map faders to probability per track, and generally fold Kria in on itself via TT. I’ve got all of these parts working in isolation, and with some clever variable management / getting my hands around it and figuring out exactly how much flexibility is actually useful, am confident I can hobble together something that, basically, infinitely plays variations on any set of values manually input via Earthsea – combined with the looper already on Earthsea KABLAM! O.o

I have a TxI, but the boards are loose and my zip tie solution has reached the end of its life cycle, halting progress on this tactile extension of my two favorite sequencers (which, really, just gives me more time to up. these. chops.)

#272

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?

Teletype concepts and thoughts
#273

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

#274

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

2 Likes
#275

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
#276

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

#277

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

#278

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
#279

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
#280

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.

#281

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.

#282

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.

#283

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.

#284

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…

#285

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.