Teletype 3.+ feature requests and discussion

scrag · 2019-02-24T17:55:30.390Z

It does seem pretty odd. As far as I can see here, it’s actually the grave accent symbol that’s displaying the live variables page - i.e. the other symbol on the key under the ESC key on the default keyboard that came with TT:

tilde

If I hit this key using the default keyboard, the live variables screen is toggled. If I hold SHIFT and hit this key, the screen displays a tilde.

My OLKB keyboard doesn’t have this key, so I’d configured the keyboard to use a key combo to generate a tilde. The key combo included a SHIFT - because the tilde is the shifted character on that key.

I’ve removed the SHIFT from that key combo (i.e. I’m sending a “`”) and all is working as it should.

What now seems strange to me is that it worked for me in the 3.0 build.

scanner_darkly · 2019-02-24T18:13:18.813Z

yeah, what you describe makes sense, other than the fact it somehow worked with 3.0. tilde is when you press that key with shift. teletype displays tilde, as expected, when you do. so the correct key for live variable display should really be grave/back quote.

i see where the confusion with tilde comes from - ASF code actually names the key HID_TILDE, which is incorrect.

scanner_darkly · 2019-03-28T03:16:08.934Z

posted new beta (see the op). added the following:

SEED, R.SEED, TOSS.SEED, DRUNK.SEED, P.SEED, PROB.SEED seed ops
(huge thanks to @alphacactus!)

SCENE.G op - load scene without initializing grid controls

rikrak · 2019-03-29T21:09:42.734Z

Fantastic! Does SEED set the seed for every random number including all the other new SEED ops? Ie Would it override a previously set PROB.SEED? (EDIT: I see I asked this back when SEED was first introduced and @alphacactus confirmed)

Thanks so much for this. I’ve used SEED in every single patch since @alphacactus first build. It’s so useful - and now it will be possible to tweak interesting loops of randomness.

EDIT 2: Testing now. Looks like R.SEED is implemented as RAND.SEED? What does P. SEED set? I thought it would set the working pattern.

alphacactus · 2019-03-29T21:46:51.418Z

ya there are a few aliases for each of the seed ops. P.SEED sets the seed for the P/PN.RND op.

SEED
RAND.SEED / RAND.SD / R.SD
TOSS.SEED / TOSS.SD
PROB.SEED / PROB.SD
DRUNK.SEED / DRUNK.SD
P.SEED / P.SD

rikrak · 2019-03-29T21:49:09.951Z

Aha. All makes sense now. R.SD is very succint! Thanks for your work!

Leverkusen · 2019-03-29T21:56:01.776Z

What does SEED mean?

desolationjones · 2019-03-29T22:25:31.817Z

@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.

Leverkusen · 2019-03-29T22:51:29.372Z

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?

alphacactus · 2019-03-30T01:15:11.883Z

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.

jlmitch5 · 2019-04-07T15:14:46.482Z

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.

scanner_darkly · 2019-04-07T17:58:16.971Z

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

a773 · 2019-04-16T05:53:53.876Z

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?

scanner_darkly · 2019-04-18T03:12:30.651Z

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.

jlmitch5 · 2019-04-19T20:11:55.786Z

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.

scanner_darkly · 2019-04-19T20:28:08.854Z

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).

jlmitch5 · 2019-04-19T20:34:28.848Z

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.

scanner_darkly · 2019-04-19T20:46:34.428Z

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).

jlmitch5 · 2019-04-19T20:59:22.663Z

Got it, thanks for the explanation!

csboling · 2019-04-21T21:54:41.797Z

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.