Teletype concepts and thoughts

[naxuu]

This was really inspiring and provided several friendly jumping off points for me, thanks.

[yams]

Concept: Kria Companion

made with an early version of this from a few days ago

I’ve been working extensively with Kria over the past year or so, and have nailed down a pretty good flow with a certain set of external controls, typically through 16n. However, I’ve recently been playing more “hands on knobs” because of certain normalizations within modules (DPO wavefolder), or else because many parameters I’d want to tweak by hand are already receiving modulation from elsewhere and I don’t have 16 free VCA/CV mixing channels lying around. This led me to neglect the 16n, since I’d be constantly riding knobs rather than faders and, in my last bigger patch, I only used three of the sixteen faders (and not particularly elegantly). So, I thought, let’s get rid of the 16n altogether and maybe even teletype while we’re at it.

This is, essentially, a “performance page” for kria tailored to my specific goals that makes heavy use of grid ops for teletype, and that I hope to transfer to satellite soon.

I’d like to say this only took three evenings, coming from lots of tt experience but 0 other coding besides, and the bulk of it was actually done this afternoon after reading about button groups and realizing all of the problems I was facing had already been solved.

I did a little sketch of the button lay out for the parameters I wanted and then set about creating SO MANY groups.

I
G.GBX 0 1 0 0 1 1 1 0 5 4 8
G.GBX 1 33 4 0 1 1 1 3 6 1 8
G.GBX 2 41 5 0 1 1 1 3 6 1 8
G.GBX 3 49 6 0 1 1 1 3 6 1 8
G.GBX 4 57 7 0 1 1 1 0 6 1 8
$ 8; $ 7

8
G.GBX 5 65 8 0 1 1 1 0 6 1 8
G.GBX 6 73 9 0 1 1 1 0 6 1 8
G.GBX 7 81 10 0 1 1 1 3 6 1 8
G.GBX 8 89 11 0 1 1 1 3 6 1 8
G.GBX 9 97 12 0 1 1 1 3 6 1 8
TR.TIME 4 11

7
J 105; K 113; D 121
G.GBX 10 J 13 0 1 1 1 0 6 1 8
G.GBX 11 K 14 0 1 1 1 0 6 1 8
G.GBX 12 D 15 0 1 1 1 0 6 1 8

So that gives us 13 groups of vertically arranged buttons, with a sorta striped pattern to help guide the eye, and with the leftmost group containing four columns of buttons rather than just one column per group. Those GROUP 0 buttons also trigger a different script from the rest of the buttons.

The first four columns I’d like to control harmonic content, with kria scale on the y axis and offset in fifths along the x axis (so that, left to right, you get I, V, II, VI, with highly limited four-note scales interior to Kria, based in part on the rings/plaits chord mode, mapped vertically, most consonant on top, most dissonant on bottom). These buttons all trigger script 5:

5
KR.SCALE + 8 G.BTNY
G.BTN.SW G.BTNI
A + * 5 G.LED 13 8 * 7 G.BTNX

This first component of A (* 5 G.LED 13 8 ) will be explained later. Otherwise this script just literally “change kria scale to Y (+ 8 cuz that’s where custom kria scales sit for me)” and “create variable A which is equal to X as expressed in fifths (+ some other fuckery)” This A is a component of all of my three “note-triggering” scripts.

The next three are per-channel offsets that scale up in fifths and octaves. This is where the key trick of the script comes out: storing values in grid row 8 via brightness (hence, out of reach). In fact, that’s all script 6 does at all. Ninety of our buttons just say “turn off the other buttons in this row and set the brightness of a non-existent square to this integer value so we can MATH it later.”

6
G.BTN.SW G.BTNI
G.LED G.BTNX 8 - 7 G.BTNY

The next three are per-channel probability faders for controlling note density.

The next three are per-channel clock dividers.

The next one is a “key” designator, which acts as a master offset in fourths (this is that first component of our variable A).

Finally we have a pair of values which are multed together to give the clock base. I like having two. different controls as one can get clean divisions at a glance or deliberately increase / decrease in a fashion that does not contain an obvious division of the prior state (by changing both values simultaneously).

Each of these groups just triggers script 6, but here’s how they get used, ultimately:

1
J / QT KR.CV 1 N 1 N 1
K / QT KR.CV 1 V 1 V 1
CV.OFF 1 PN 0 G.LED 4 8
PROB - 100 * 14 G.LED 7 8: BRK
CV 1 + V K N WRP + A J 0 11
TR.P 1

Set local variables J + K to nice clean semitone and octave values, respectively. Set the lowest possible note to some number from this list:

P0
0
7
12
19
24
31
36
43

corresponding to the position of the fader on column four. If column seven is set very low, probably stop here. But maybe don’t. If not, trigger a note that folds together the proper key and chord offset (on top of the octave / fifth “master offset”) and wraps, maintaining the integrity of any octaving coming from kria.

The next two scripts are duplicates of this, incremented by one in key locations:

2
J / QT KR.CV 2 N 1 N 1
K / QT KR.CV 2 V 1 V 1
CV.OFF 2 N PN 0 G.LED 5 8
PROB - 100 * 14 G.LED 8 8: BRK
CV 2 + V K N WRP + A J 0 11

3
J / QT KR.CV 3 N 1 N 1
K / QT KR.CV 3 V 1 V 1
CV.OFF 3 N PN 0 G.LED 6 8
PROB - 100 * 14 G.LED 9 8: BRK
CV 3 + V K N WRP + A J 0 11

And then in the metro script…

EVERY + 1 G.LED 10 8: KR.CLK 1
EVERY + 1 G.LED 11 8: KR.CLK 2
EVERY + 1 G.LED 12 8: KR.CLK 3
J * G.LED 14 8 G.LED 15 8
M * J 30; TR.P 4

I’m posting all this in part to force myself to audit my own work (found two mistakes!!!), and in part to encourage people to take advantage of 1) this awesome thread 2) FUCKING AWESOME GRIDOPS!!! and 3) satellite.

The last part is to ask a little aaaaaaaaaadvice. Are there any overtly dumb things going on here? Something super clunky for no reason? I want to turn this into a satellite script and migrate TT out of my main case (because this is all I’ve been using TT for for a looooooong time), but want to make sure this is smooth sailing first. I know Satellite only has two trigger ins – could I just set it to poll Kria’s trigger outputs in the metro like so: “IF KR.TR 1: $1”, or will this upset the I2C gods? Finally: I’d like to create a per-note keymap for the leftmost quadrant of the grid to highlight “safe” harmonic choices and aid in learning the moves from a set of ~12 possible next moves each rather than 32 – is there a good way to do this in 1 script, possibly storing data in the tracker / unused grid buttons / both? That leap still isn’t happening for me…

Also let me know if there are any questions about this. The thought of a custom Kria page is… Amazing. Then thinking “custom page for ANYTHING” is just… Too much.

[SimonKirby]

This looks really fantastic and gives me another push to revisit grid ops (which so far I’ve found a little on the wrong side of the planned coding / live coding divide for my tastes). I’m very keen on the idea of using Teletype as a metasequencer for kria (and also, perhaps, the other way around)! Can I ask, do you have two grids? Or do you have a reliable way of switching the grid between the two modules. I’ve tried various cables and switches but it’s always ended up being a bit clunky and/or noisy.

[yams]

@SimonKirby

gives me another push to revisit grid ops

!!!

This has worked for me but ymmv. I’ve found tt and grid noise to be magically disappearing / reappearing type things, varying due to which wall it’s plugged into, how many LEDs are lit, etc.

I will say that this particular page I use instead of grid control of Kria, not in addition to. My sequences are “prepared” in an extra-especial fashion to work well with this particular set of manipulations.

[scanner_darkly]

sorry, finally found the time to reply - this is totally amazing!! the scene itself and the detailed breakdown both.

this is such a great example of how you can essentially add your own features to kria, earthsea and any other i2c controllable apps - all the way to creating your own interface for them! i love the fact that you didn’t just expand kria’s interface but replaced it with your own. and yeah, a good way to use satellite as this is something you likely to build once and then maybe only tweak occasionally (also a reminder for me to fix the bug in satellite).

---

in terms of the script itself not much to add, really! it’s very straightforward and shows that you don’t really need a complicated script. glad you took advantage of groups, it would be difficult to achieve same functionality in a limited script space.

@yams

I want to turn this into a satellite script and migrate TT out of my main case

you’ll need something to provide power/pullups for i2c - do you have anything on your i2c bus that would have that? if you’re just planning to use ansible/kria + ansible/satellite you’ll need an i2c backpack or something similar (txb would also work).

@yams

could I just set it to poll Kria’s trigger outputs in the metro like so: “IF KR.TR 1: $1”, or will this upset the I2C gods?

should be fine!

@yams

Finally: I’d like to create a per-note keymap for the leftmost quadrant of the grid to highlight “safe” harmonic choices and aid in learning the moves from a set of ~12 possible next moves each rather than 32 – is there a good way to do this in 1 script, possibly storing data in the tracker / unused grid buttons / both?

yeah i would say use patterns to store coordinates or something like that and then set them in a loop. and then use G.LED with brightness level set to -2 - that’s a special value that will “brighten” whatever is underneath, including buttons.

clever trick with storing values in unused LEDs! you’re limited to range 0-15 though. i’d use fine faders instead with G.FDR.V ops. you can store 64 values this way.

have you seen the awesome ANS.G ops @csboling added a while ago? you’re not limited to app specific i2c ops - you could emulate any grid press or a combination of presses.

[yams]

“This is great; recode everything” – the best kind of feedback!

Really though: switching to faders is gonna help save a ton of space (in subtle ways)! Lots of other gold here, too

I’ve never done anything with loops but will hopefully start tinkering tonight after the rebuild. Expanding harmonic vocabulary was the real catalyst to move to this (vs a single button that changed keys in fourths) and it’s a little difficult just hunting and pecking for transitions lol.

I was thinking to put Crow + JF on the I2C bus. Crow should gimme the pullups needed, right?

[desolationjones]

@yams

Crow should gimme the pullups needed, right?

Yes, as long as you haven’t disabled the pull-ups in your user script (for whatever reason).
JF running 4.0 firmware also provides some weak pull-ups.