#258

I’m most interested in a way to distribute random as well…

#259

Hello @scanner_darkly, I would like to implement I2C-OPs for the ZRNA FPAA board. How do we start this correctly? Current I2C address seems to be 0x15, is that ok, or will there be a conflict with existing hardware?

Main site: https://zrna.org
Examples: https://zrna.org/docs/quickstart
Existing python I2C client: https://github.com/zrna-research/zrna-api/blob/16a4fa981e5e21202a0ad78a9b18ffa298ef17d0/zrna/util.py
Definition of remote procedure interface: https://github.com/zrna-research/zrna-api/blob/16a4fa981e5e21202a0ad78a9b18ffa298ef17d0/proto/zr.proto

#260

you don’t need to add ops - you can just use the existing generic i2c ops added in the latest beta (posted in the OP): https://github.com/monome/teletype/blob/main/docs/ops/i2c.toml

#261

Just a quick idea regarding the complication of entering the pattern backwards…
How about an OP that simply reverses an input (before it is evaluated)?

REV 23 // gives 32
REV 110 // gives 011

That op could be working on B numbers as well.

B1101 // gives 13
REV B1101 // gives 11

Then one could enter the pattern in correct order, reverse it and then use DEL.B:

DEL.B REV B1101
results in “ping! ping! (rest) ping!”

Not sure if this makes it more complicated than before. But a generic “reverse” operation could be interesting… ?

1 Like
#262

you don’t need to add ops - you can just use the existing generic i2c ops added in the latest beta (posted in the OP):

The recipient will not understand such commands at the moment - it uses I2C to transmit serialized protobuf messages; there are dozens of different object classes which take hundreds of named parameters, as you can see from the .proto file I posted in my last comment.
So I thought of using an embedded protobuf library like nanopb to create ops (https://github.com/nanopb/nanopb).

If you look at the example in the quickstart (https://zrna.org/docs/quickstart) I imagine it like this on the Teletype (OPs can be shortened):

Z.CLEAR
Z.PAUSE
G Z.GAININV
Z.GAININV.GAIN G 100 
I Z.AUDIOIN
O Z.AUDIOOUT
Z.ADD I
Z.ADD O
Z.CONNECT I G  (or Z.OUT I Z.IN G) 
Z.CONNECT G O (or Z.OUT G Z.IN O) 
Z.RUN

It might work with generic ops IF I would write an external protocol bridge, transcoding messages with protobuf, so the ZRNA board would understand. Still, I am unsure if complex OO parameters-as-commands (such as GAININV.GAIN, OSCILLATOR_SAW.OSCILLATION_FREQUENCY etc) are supported.

I could of course limit the level of control to setting a few numerical parameters, or introduce abbreviations.

Do you think using an embedded protobuf library such as nanopb would be outside the capacities of the platform?

#263

I built a TXi yesterday and, remembering this post from Trent about Crow’s hybrid leader-follower behavior, wondered if I could get TT to behave like this so I didn’t have to give up “follower mode” on the TT:

I haven’t exactly stress-tested this code, but TT seems to be perfectly happy doing exactly that if I init leader mode in the two TT leader functions, and then re-init follower mode right afterwards. Crow is able to trigger TT scripts and TT is able to read values from TXi.

4 Likes
#264

great to see it works! yeah i would say we would need to stress test it extensively, super fast metro with lots of both reading and sending i2c commands, several devices and several leaders.

1 Like
#265

are you thinking of adding this to the official firmware or just in your own fork? for the official firmware this looks like a large language extension, so it would need to be something that would be a fairly common use case.

hard to say without trying it. also keep in mind you’d likely have to reimplement the current i2c stack in libavr32 since it’s not really designed for such heavy communications.

1 Like
#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!