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

yeah not sure what might be causing it. the command bytes you chose seem fine. i should mention that ii.h is not the definite list of all the commands used, some firmware could just use its own constants, it’s more of a recommendation to put any new commands there. i don’t think that’s the case here though, i checked the ansible code and i only see commands defined in ii.h. one theory is that maybe due to sending to several addresses at once something gets garbled and it misinterprets the command.

for teletype the convention that was agreed on in one of the tt threads was that we should make everything 0-based (even though there are some ops that use the 1-based convention). also, LV.CV and CY.CV ops are 0 based.

re - page ops - had the same thought, will definitely help with both making usage of ANS.G more predictable and efficient, and will help with something like where you emulate a bunch of presses, say, to randomize some parameters, and you are triggering that script from some external source, but you don’t want this to be applied on every page. and probably doesn’t need to be app specific, but could add another op to return what app is currently running?

also thinking, might be useful to have ops to emulate module button presses?

1 Like
Teletype I2C protocol
Monome ecosystem firmware development backlog
#307

another idea for the new ops - performance recorder.

have one grid attached to ansible, another grid attached to teletype. create a script that reacts to grid presses and passes them to ansible. another button enables recording - in addition to passing presses to ansible it stores them in pattern banks. another script can “play” stored grid press sequences.

this can be used as a way to quickly store/invoke key combos, or a way to record a performance. if you use this with multiple scenes you could in theory automate your whole performance… (especially if we add an op to switch ansible apps).

5 Likes