#286

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
Ansible bug reports (official)
#287

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

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.

#289

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

Got it, thanks for the explanation!

1 Like
#291

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
Monome ecosystem firmware development backlog
#292

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

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
Teletype and MIDI
#294

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.

#295

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

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

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

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

Hello sorry to bug
As my placement and timing for this question is probably off
(Such is the way of my life)
Any way
Can I fire off a scene from a script?

1 Like
#300

you can’t execute a scene from a script but you can switch to a different scene with SCENE op, then use it to switch back.

this is a better thread for general questions: Teletype workflow, basics, and questions

2 Likes
#301

Not sure if this is the place to request this, or if its possible, but more 16n integration would be nice.
Like:
FADER.MAP x y z to constrain cv values of fader x between y and z.
FADER.SCALE x set scale to be used for fader quantization.
FADER.QT x return quantize value of fader x to scale
FADER.N x return note value of fader x to scale

Monome ecosystem firmware development backlog
#302

i purposely kept the implementation simple in order to maximize the out-the-door “hackability” of the unit. That said, it shares the same i2c framework with the TXi. Porting those features over and including them would be a fairly easy exercise.

1 Like
#303

I love your Telex modules and their awesome functionality is what inspired me to request similar for the 16n.

1 Like
#304

Interestingly I thought I had messed this up because suddenly all my ANS.G.LED reads were coming back 27, but turns out I had a different Ansible firmware image loaded. This is maybe straying into a development question for another thread, but what’s odd is that I do initialize this value before the reads:

    d[0] = 0;
    tele_ii_rx(II_KR_ADDR, d, 1);
    tele_ii_rx(II_MP_ADDR, d, 1);
    tele_ii_rx(ES, d, 1);
    cs_push(cs, d[0]);

So what I don’t quite understand is why tele_ii_rx is reading 0x1b from one or more of these addresses when nothing there should be responding to the message I sent. The command bytes I chose but might not be the best long-term are:

#define II_GRID_KEY     16
#define II_GRID_LED     17
#define II_ARC_ENC      24
#define II_ARC_LED      25

so I don’t think there should be any collisions. Not clear to me if this is at the protocol level, a quirk of the driver stack, or something else I’m missing.

Unrelated: should Arc rings be numbered 1-4 for ANS.A ops instead of 0-3? Not sure what’s conventional with Arc – Grid ops are zero-indexed so I stuck with that, but TT/Telex (and Lua :bird:) start at 1.

#305

Okay so this is fantastic fun:

A ANS.G.LED 6 7            # Kria note page button
IF GT A 4: BREAK           # <= 4 when not on note page
ANS.G.P 6 7; ANS.G.P 6 7   # press it twice to go to alt-note
X RRAND 0 15; Y RRAND 0 6
ANS.G.P X Y
ANS.G.P 5 7                # go back to trigger page

However this is kind of verbose and potentially hard to decipher since you have to figure out the placement of the page buttons you want and do LED brightness comparisons to check state. But what if you had:

KR.PG     # read the active page 
          # maybe 1-10?
          # - odd primary pages
          # - even alt pages
          # - 8 for future duration alt page
          # - 9-10 for scale + pattern
KR.PG x   # set the active page
          # returning the page before the change

Probably this particular example can be achieved with less communication expense and head scratching, but I imagine you could easily get much weirder. I’m just immensely enjoying Kria Plays Kria over here. Such a good jam buddy!

3 Likes
Monome ecosystem firmware development backlog