#1

discussion and beta builds for teletype firmware post the 3.2 release

this is a thread to suggest and discuss new features for teletype. this is where you will find the latest teletype builds until a new official release.

if a feature requires a separate discussion thread, create one under Development category, tag it teletype and post a link to it here.

relevant threads / resources:

teletype 3.2.0 thread
previous discussions thread
github issues/enhancements

latest “official” beta:

CB56E83

updating firmware will erase your existing scenes, make sure to save to USB first!

teletype.hex (668.7 KB)
teletype.zip (192.7 KB)

updating firmware will erase your existing scenes, make sure to save to USB first!

experimental builds (might not contain everything from the “official” beta above):

W/ integration - needs to be rebased
Scale quantizer OPs, bit-masked delays and quantizer - needs to be rebased

10 Likes
Teletype MIDI IN ops [experimental]
Teletype Disting EX integration
A user's guide to monome eurorack firmwares
Teletype 3.+ feature requests and discussion
> teletype: grid # code exchange
A user's guide to the wonderful world of teletype ⌨
Teletype workflow, basics, and questions
Teletype MIDI IN ops [experimental]
Teletype Disting EX integration
Teletype MIDI IN ops [experimental]
Satellite: run teletype scenes on ansible
Teletype Disting EX integration
Teletype firmware discussion
> teletype: grid # code exchange
Satellite: run teletype scenes on ansible
#2

20 characters of please add MIDI :heart_eyes: :crazy_face:

3 Likes
#3

I was looking at old issues in GitHub recently and came across the one for AT. Have most TT users lost interest in AT now that we have DEL.R? I still think it would be cool to be able to have multiple scripts repeat at intervals that could be changed on the fly (whereas – AFAIK – once you’ve called DEL.R, the time between subsequent retriggers can’t be changed).

Or is AT-like behavior already possible without a dedicated op? Before I read about AT, I tried doing something similar where script 1’s last line was DEL A: $ 1 and script 2’s was DEL B: $ 2, but I never got that to work quite the way I expected – it seemed like the two delays would sometimes interfere with one another, because eventually one or both scripts would stop retriggering.

#4

this is because you’re calling a script from itself, and teletype limits recursion count to 8, otherwise you could get into an infinite loop. so yeah, it’s not a 1:1 replacement for AT.

1 Like
#5

Oh, that explains it! Would it be simpler (or even possible) to allow infinite loops when scripts call themselves using DEL (since DEL.CLR would end the loop)? Then AT wouldn’t be necessary, at least for what I was trying to do.

#6

when a script is called from another script, teletype needs to preserve some script context, which is why it was limited to 8 (not 16 like i said previously, i’ve double checked the code). this limit actually applies to scripts called from other scripts, not just scripts calling themselves (so you couldn’t bypass it by calling script 1 from script 2 and then calling script 2 from script 1). so yeah, wouldn’t be easy to change. AT is probably a cleaner solution.

1 Like
#7

One of the things I have been wishing for is a simple way to latch a script to the global metro, without having to throw a call into M or a separate page.

When I am working from just internal clock, my M page is usually reserved for calling scripts. But if there was a dedicated page, to just like latch each script to global metro (maybe even with dividers? or multipliers! random walk even!) that would be so handy.

I’ve been experimenting mostly with internal clock recently, trying to save some skiff economy by not having a dedicated clock module

1 Like
#9

One thing I would love is to be able to send messages from Teletype to Crow. As crow is a programmable module this would open up a lot of possibilities :slight_smile:

6 Likes
#10

I have recently thought about virtual scripts (#11 - #…) to expand programming space.

#11

I’m kind of wondering what teletype crow ops would look like - what they could do.

It would be pretty neat to be able to set/read crow variables with the teletype, but I don’t know if that’s possible or not? Since crow can run lua scripts, it’s not like there’s a finite number of pre-defined variables. They can be named anything, and be more complex than unsigned ints.

That’s probably my biggest wish for crow - to be able to set some configurations without necessarily having to boot up a computer. Being able to do that at specific times, e.g. through a clocked teletype script would be pretty amazing.

3 Likes
#12

I think you could have set functions that you could program way to answer in crow.

For example, in teletype:

CROW.TR 1 1

CROW.CV 3 N12

could be handled in crow with

function tr(id, val)
    if id == 1 then
       -- call something using val
    end
end

function cv(id, val)
    -- do something with it
end

with this you could do a lot of things already, send notes, trigger different modes on crow, etc

1 Like
#13

crow already works well as a follower, Teletype just needs the ops added. The proposed set of TT ops:

CROW.OUT channel level
CROW.SLEW channel time
CROW.CALL1 arg1
CROW.CALL2 arg1 arg2
CROW.CALL3 arg1 arg2 arg3
CROW.CALL4 arg1 arg2 arg3 arg4
val <- CROW.QUERY0
val <- CROW.QUERY1 arg1
val <- CROW.QUERY2 arg1 arg2
val <- CROW.QUERY3 arg1 arg2 arg3

The .OUT and .SLEW ops are intended to echo the on-board TT output syntax for ease of integration. It would be relatively easy to add the .TR style accessors too if that’s desired. These are handled behind-the-scenes, so you don’t have to write any lua to have them just work.

The .CALL and .QUERY are intended to be backed by a lua event handler that allows you to do fancy things. A very basic examples would use crow to store a big array:

CROW.CALL2 index value      // set index to value
value <- CROW.QUERY1 index  // retrieve value at index

Getting feedback from TT users would be great. If something like the above is a mainstream usecase, it could be simplified to just CROW.VAR which set an index to a value, or take an index and return a value. Making that work natively is easy, I just don’t want to bloat either platform with un(der)used functionality.

If you’d like to help add the Teletype firmware side of these functions that’d be highly appreciated - please see this github issue. If you’d like to discuss the crow side’s syntax, see this PR. The lua syntax, and TT op list are still open for discussion here.

16 Likes
#14

Thank you for the insights! I’ll have a look at the PRs, this is exciting stuff :slight_smile:

#15

And Crow talks MIDI, right? (I’m still playing the same tune)

#16

Hmmm… I wonder if this could be relaxed for SCRIPT calls at the last line of a script? This would essentially allow tail recursion to be treated like a simple loop since presumably context would then not need to be preserved?

#17

What’s the closest thing we have to a “getting started with teletype firmware development for dummies” guide?

3 Likes
#18

Actually, Crow doesn’t EXACTLY talk MIDI, while it’s in there it’s not fully optimized or ready for prime time.

If you look, there’s actually some basic MIDI implementation by the TT at the moment. It’s not in the firmwares, but @scanner_darkly got some cool examples up here somewhere on lines.

The main issue was getting MIDI out to work right. Midi in was getting some cool examples. If I remember, it was dropped because MIDI protocol wasn’t Scanner’s number one comfort zone. I also recall someone briefly mentioning that they’d take a bit of a stab at it.

If anything, this is eventually on its way, maybe not today or tomorrow, but given the recent open source of the TT, SOMEONE will take up the mantle!

Also, @scanner_darkly, if I’m off, please, correct me! I just remember seeing most of this when I was looking through old threads a month or two ago.

#19

Some useful information on how to get set up to build is in the README.md in the repo. Most other stuff I think is just kind of getting familiar with the code structure, though that file does sketch how to add an op. Discussions on lines I think largely tend to be geared towards specific deep-in-the-weeds technical topics or revolve around feature development.

2 Likes
#20

it would still not prevent an infinite loop which is the main reason to only allow limited recursion (originally teletype didn’t allow recursion at all iirc). but in most cases you shouldn’t need recursion (you could just have one main script, like metro, calling others as many times as needed) - is there a particular use case you’re thinking about?

it wasn’t MIDI (which is simple), it’s the USB spec (gory details here). but yeah it was sending MIDI that didn’t work fully. receiving MIDI was fine and i’m planning to revisit it (no promises though, it’s possible it won’t fully work either - needs to be tested with various devices etc). here is the main thread on: Teletype and MIDI

1 Like
#21

yeah as @csboling mentions, take a look at the readme. once you have the toolchain set up and can build firmware, take a look at any pull request that added an op - it should give an idea of what’s involved.

for code structure take a look at this: Teletype firmware discussion

1 Like