Teletype 3.+ feature requests and discussion

@Leverkusen computer-generated random numbers come from algorithms which are not actually random, so it’s important to feed these algorithms with a good source of randomness to “jump start” them. hence the “seed” values. but if you use a known seed then you will get a known result. in other words, you can use the SEED OP to retrieve a predictable string of results from the related OPs.

1 Like

Thank you for pointing that out! So the idea is that a certain random behavior can be part of something like a preset, or scene in this case?

What data does the SEED expect? A single number? A row of numbers? You can guess that I have no idea how this actually works behind the scenes and what kind of algorithm is working the random result out. Is it a bit like the CHAOS functions @sliderule implemented in the 2.0 firmware?

1 Like

SEED only requires a single number. for example if I were to do SEED 101 then call RAND 5 three times I might get a sequence like 5, 2, 3. then if once again did SEED 101 and called RAND 5 three times I would get the same sequence 5, 2, 3. so you only need to call it once with a single number, but each time you call it with the same parameter value you will repeat/restart the random sequence.

8 Likes

I’ve noticed an issue where if I switch back and forth between keyboard and grid (with grid control mode active)., and I have a script going with the metro acting as the clock, the clock will have a laggy beat (as I guess it loads things on the grid) causing things to slow down for a second.

If it’s possible to have the audio loop maintain “preference” (and grid control mode take longer to load if necessary) that’d probably work better in my particular use case. That being said, I have no idea how difficult or feasible of a change that would be.

it’s likely the fix i applied to ansible will also work for teletype. will try to post a test firmware today.

1 Like

I’m not sure this is the place, but I have a minor suggestion for the TT firmware: When moving scenes around, it would be nice if the TT would display the “help screen” of the location you’re hovering over, not the one your are about to save. Makes sense?

sorry, just got around to making a test version for you. unfortunately, the fix i did for ansible didn’t really fix the issue for teletype, i’m still seeing an occasional delay. but it’s possible it’ll happen less often now or the delay itself will be smaller, give it a try: teletype.hex.

any further optimization would be difficult i’m afraid, this would require a pretty significant refactoring to have different priority queues. and then a bigger question is - what should take priority? timing accuracy? or responsiveness? these are conflicting requirements - if you give timer higher priority it’ll have better accuracy but at some point you’ll get key presses getting dropped.

2 Likes

thanks! just had a chance to test, and I am hearing no lag.

with M 140 and the M script

TR.P 1
PN.NEXT 0
PN.NEXT 1
PN.NEXT 2
PN.NEXT 3

and grid control mode focused on the pattern screen, I toggled quickly between keyboard and grid mode with the TWO:ONE.

The signal I had triggered was audibly rigid on the new firmware, where it used to lag every time the grid control mode screen was switched to and “prepared”.


The only weirdness was after update, the "this will overwrite flash memory screen displayed for a second or two, followed by a blank screen and TR leds 2 and 4 lit. This same behavior was present after a few power refreshes. It went away once I pressed the button in the 1 or 2 seconds the message was displayed.

EDIT: Note that it may be possible there is still a delay with more intense use of teletype I typically do (multiple gates and cv sequences controlled by EVERYs from the internal metro), but I don’t have things set up to test that out at the current moment. I will keep you posted as I prepare a patch for performance in the next coming weeks.

1 Like

re: the message - that’s a new warning we added in 3.+ beta as a way to prevent the issue with flash scenes getting blanked out randomly. you will see this message every time you update the firmware. just press the button as it suggests, and the message will go away. you should never see this message during normal operation (if you do that means you ran into the flash issue - try power cycling teletype and see if the message goes away, and then backup your scenes to USB immediately and let me know).

1 Like

gotcha. I did have a realization I was gonna lose my scenes because I forgot to backup before starting the upgrade (which is fine, nothing is permanent)

But when that message came up the first time, I did attempt to turn off my system, plug my usb drive in, and then turn it back on (which is how I backup normally, if I remember correctly). when I restarted the message showed up for a few seconds and went to the 2/4 LEDS lit with blank screen, the same as if I didn’t have anything plugged in.

TL;DR the backup to usb flow may be broken on upgrade.

sorry - i should’ve added the usual warning when i posted the firmware… unfortunately, as soon as you flash the firmware your scenes are gone - USB backup won’t do anything at this point.

the idea behind the message is that it’s warning you it’s about to reinitialize flash. if this happens during normal operation, that means something went wrong, and the message is there as a safety measure, to prevent it from overwriting your scenes.

but when you flash a new firmware, flash memory at this point is filled with garbage, so you do want it to reinitialize flash, and until you do it’ll just start in some funny state, which is what you’re seeing.

btw - you can backup to USB at any point, not just at startup (@sam changed this a while ago).

3 Likes

Got it, thanks for the explanation!

1 Like

Not sure if this idea has been discussed elsewhere, but I wrote a proof of concept of the following op:

ANS.G x y    # read ansible's grid LED buffer at position (x, y)

ANS.G x y z  # simulate a grid event on ansible
             # as though grid button (x, y) were pressed

teletype.hex (569.4 KB - 8b6bd77)
ansible.hex (246.6 KB - 6227489)

This might be more aptly called KR.G right now since only Kria will work, I think a different i2c address would have to be targeted for e.g. Meadowphysics to have handlers for this message? On these branches I edited libavr32 to add a II_GRID message type (== 16) since I reckon the same idea could apply to anything else with grid support.

3 Likes

cool idea! i can see several useful applications for it. i’d say it’s probably better to use 2 different ops instead of the same one (like ANS.LED and ANS.G) - we might want the ability to set LEDs and read grid button states in the future.

unfortunately, you’re right in that the i2c address is app specific, so it would need to be a separate set of ops for each app. one way around it would be to just have teletype send to all 3 ansible addresses (kria/mp/es).

another thing to consider is something like ANS.G.P for emulating grid press/release (otherwise you’d have to use 2 lines: ANS.G x y 1, then DEL 20: ANS.G.x y 0). this would require adding up to 256 internal timers though - which might be too much…

probably a couple of ops for arc as well?

3 Likes

Right on, I don’t have an Arc to test with but I think these should work? Interactions with the Arc application state are in these functions.

(outdated, current build below)

teletype.hex (573.2 KB - 9d2c440)
ansible.hex (246.9 KB - b67e8bd)

Ops in these builds:

ANS.G x y z    # send on/off (z) for grid key x, y
ANS.G.P x y    # simulate press (on followed by off) of grid key x, y
ANS.G.LED x y  # read grid LED buffer at position x, y

ANS.A n d      # send arc encoder event for ring n, delta d
ANS.A.LED n x  # read arc LED buffer for ring n, LED x (clockwise from north)

These all now send/receive from all Ansible addresses at once. This includes Earthsea on the Teletype side but this Ansible firmware build does not contain Earthsea. I should really add this to Ansible Earthsea too because now you can more easily do multi-key gestures in scripts. Consider:

Meadowphysics in 2 voice mode
Ansible gates 1 & 2 -> scripts 1 & 2

# 2
X RRAND 1 15; Y RRAND 0 7
ANS.G X Y 1; Z 1

# 1
IF EZ Z: BREAK
I MAX 1 - 15 X
ANS.G.P + X RRAND 1 I Y
Z 0; ANS.G X Y 0
4 Likes

this is great! don’t worry about ansible earthsea - once your change is pulled into the ansible master branch i can rebase and post a new version.

how are you doing .P, a press immediately followed by a release? donno why i was thinking this would require a timer since you could just do this.

Yes, this works with just tele_ii_tx twice. I didn’t have to change anything on the Ansible side for that. Also happy to discover that I could use tele_ii_rx with multiple addresses when reading LED state without causing TT to hang waiting for non-active apps to respond.

1 Like

thinking of some interesting ways to use this… with earthsea this could be used to transfer sequences from teletype. or you could even use earthsea to record sequences from external sequencers (via tt input or telexi).

with grid ops this could also be used to have 2 grids control the same app (it’s probably not going to be fast enough to poll for all LED states and transfer them to the 2nd grid but doing some basic reflection of the main grid and passing presses from the 2nd grid should be doable).

1 Like

works great, and lots of fun:

in this video i’m using it to randomize/reset current parameter and to set the sequence length with the tt knob. using another grid to trigger tt scripts.

are you using address 0 for any of the i2c stuff?

2 Likes

Awesome, thanks for trying it out!

The only addresses I used were II_KR_ADDR, II_MP_ADDR, II_LV_ADDR, II_CY_ADDR, and ES - just sending the messages to all the relevant addresses for a Grid/Arc command seems to work pretty well. The broadcast address would probably be more efficient but I was hesitant to do that since it seems like you might only want Teletype manipulating the grid for one device rather than everything on the bus.

1 Like