#8

Okay, so I reread the line; basically, if a button pressed equals 0, then it breaks that line, meaning it doesn’t run the rest of the scene…
Is that correct?

#I
G.BTX 1 0 0 1 1 0 0 9 16 8

#M
IF ! G.BTNV: BREAK
A G.BTNX
SCRIPT + 1 G.BTNY

I’m reading Study 6 (which I would like to start going back through this again this weekend) I see the competitors and understand. Thanks!

#9

Incredibly interesting and helpful, thank you for posting these!

Just curious, what’s the module and how are you using it with TT? :grin:

1 Like
#10

I feel like this is one of the more basic answers, but the module is an ER-301 :smiley:

They’re just so hard to come by I almost felt bad bragging about it. It’s why I had wanted a TT all along. Having the ability to trigger so many things with simple scripts is a big big plus for me. It allows me to do a lot with a selective few modules.

With the TT and ER-301 connection, I’m dying to try getting the arc involved, having Max patches output i2c signals instead of midi through crow.

1 Like
#11

this doesn’t sound correct - it will evaluate to false on non zero values.

! x will return 1 (equivalent to “true”) if x is 0, and 0 (equivalent to “false”) for any other value. used with IF:

IF ! x: ...

it means: only execute this line if x is 0.
this line:

IF ! G.BTNV: BREAK

is typically used with momentary buttons since the script is called both on button press and release. so if only want to take action on button press, you check the last pressed button value (G.BTNV) - if it’s a release, the value will be 0, so ! G.BTNV will evaluate to true and it will break.

for a second i thought you mean the actual whitewhale module :slight_smile:

3 Likes
#12

How stupid can I be???

You’re obviously 100% correct, my brain must have been… I don’t know what.

Let’s do some simple example lines, that will all fire TR 1 (hope I don’t mess it up this time as well):

TR 1
IF 1: TR 1
IF ! 0: TR 1
1 Like
#13

forgot to update the metro script at the end - updated my post!

#14

concept: patch/preset manager

imagine a micro system that is fully repatchable from teletype. change your whole patch by pressing a key. teletype as the heart of a system: this is the concept i want to explore in this post. using teletype as a preset manager might seem like underutilizing what it’s capable of, but i think it’s the exact opposite, and a good example of how teletype can “glue” a whole system together.

let’s look at preset management first.

what kind of presets can we store? the most obvious example is modules that have no presets but have CV inputs for the parameters you want to store. then it’s as simple as using teletype CV outputs to control those (or using trigger outputs to control gate inputs). with teletype alone you can control 4 CVs and 4 gates. if you need more than that, you could use ansible or telexo to gain another 4 CV and 4 trigger outputs.

the downside to this is that you have to use teletype to change these parameters (or use the knobs and then approximate the knob values with your script). you can address this by using the teletype knob and recording snapshots as shown in the preset morpher post above. still not great, since you have to record each value separately, but this could be addressed by using a midi controller and the midi in ops.

this might still seem fiddly but here is what you gain: you can control CVs more precisely, you can switch multiple CVs at once and you can have multiple banks of values. something like pressure points can be used in this manner and gives you 4 sets of 3 CVs - with teletype you can record and recall 64 sets of 4 CVs (using pattern banks) - and that’s just one scene. and you can do other interesting things, like morphing between different snapshots (i will refer to the post above again).

some modules have their own preset management, and in many cases teletype can be used to control those as well. trilogy and ansible come to mind first - whitewhale, earthsea, meadowphysics, ansible can all store presets, and you can select them with ops:

whitewhale: WW.PRESET x and WW.PATTERN x
earthsea: ES.PRESET x and ES.PATTERN x
meadowphysics: MP.PRESET x

ansible ANS.APP x to select an app
kria app: KR.PRE x and KR.PAT x
mp app: MP.PRE x
es app: no ansible versions, use the earthsea ops above
cycles app: CY.PRE x
levels app: LV.PRE x

with ansible ops you can also get the current preset and pattern (where applicable) if you don’t supply a parameter.

other modules / firmwares that allow you to select presets via i2c:

orca: OR.BANK x and OR.PRESET x
disting ex: EX.PRE x
matrixarchate: MA.PGM x

not all i2c enabled modules support preset selection via i2c (you can’t do it on er-301, for instance). not all need it - for something like telexo and just friends it’s just a matter of using individual ops to get them into the desired state (using something like JF.MODE and TO.ENV.ACT).

you can also control various select bus devices - rene mk2, voltage block etc. you will need to use expert sleepers disting ex module for that, and then use the select bus ops and refer to the select bus specification. and if you add a midi breakout, you can also send MIDI program change messages, so you could even control presets on various MIDI devices!

now, what about patch management?

to control an actual patch we’ll need to employ additional modules - VCAs and switches. you could plug an LFO into several VCAs and send it to multiple destinations, for instance, and use teletype CV outs to control which VCAs are open, thus controlling the patch. voltage controllable switches, similar idea: you could use teletype trigger outs with something like doepfer sequential switch or CV outs with doepfer voltage contrllable switch. there are many similar modules to choose from.

you could also implement a patch matrix. you have several options: use something like 4ms vca matrix and 3 telexo modules (which will give you 12 CV outputs, and you have 4 on teletype, so 16 altogether) to control its nodes. not the most practical option perhaps! you could also use disting ex’s matrix mixer algorithm which gives you a 6x4 matrix which you can control directly via i2c. finally, sssr labs sm010 will give you a 16x8 matrix, also directly controllable via i2c - just be aware that it has several quirks that might make it not suitable for your purpose (see the thread for details). grid interface would work really well for controlling a patch matrix.

ok, this one is for completeness sake - you could also store patch notes in a scene description :slight_smile:

as you can see, you can recall many different things via teletype, which makes it a really powerful preset manager. there are many ways you could go about it too.

you could simply have each scene set up various parameters and load specific presets on other modules, and then just load scenes to switch patches. you could store multiple snapshots (both CVs and preset numbers) in one scene using pattern banks.

you could do something more interesting - like the already mentioned morphing between different snapshots (this won’t work for loading presets on other modules, of course). another idea: meta controller. build a grid interface to control presets on other modules all in one place. or take it further and build a meta sequencer that sequences presets (just take into account that it might take some time to load a preset, depending on the module).

or how about this: imagine a grid scene that is set up like a dj mixer. left side selects presets on, say, ansible and earthsea, right side selects presets on disting ex and voltage block. so 4 chains, each one with its own sequencer and sound source. teletype CVs control VCAs so you can control volume of each chain independently. you could program a crossfader too. then you could build a performance where you select a new preset while it’s playing the other side, switch parts gradually, combine them in different ways, all played from a grid.

i would really love to see more discussion in this thread too - please share your own thoughts and ideas or if you got inspired and implemented your own variation of any of the concepts described here i would love to learn about it!

19 Likes
#15

2 posts were merged into an existing topic: Teletype workflow, basics, and questions

#16

I’ve had this drafted here since this topic started, wasn’t sure if you wanted other people to share or if this was more of a diary/log type thing—been really enjoying your ideas thanks for all your work and for sharing!

teletype as nested sequencers

in my smallish case, teletype is really my only sequencer-like-object. I’m working on creating a basic scene which I can use as a starting point when creating songs or performances, rather than building from scratch every time. I don’t really have anything sending gates or triggers in to Teletype, so I wanted to be able to have complex rhythmic control over internally triggering scripts, that was the starting place…

This is basically what I have so far—it’s quite basic and I’m sure I will build on it and it may become slightly more complex. The benefit of it is that I can pull up a rhythm or sequence quickly. The more complex the basic building block is the less open ended the building becomes, so it probably wont get too much more complex… I am not a super proficient Teletyper, but I hope this can show that even luddites like myself can learn a couple key tricks and get the tool they need. Big shoutout to Teletype Talk.

  1. I wanted a tempo knob and I found myself not using param much so I put it to use :slight_smile:

    #I
PARAM.SCALE 60 240

#M
M BPM PARAM
L 0 7: $ 8
P.N 0; P.NEXT

  2. Working backwards sort of, but if you understand bitwise ops you can see here I’m using script 8 to trigger scripts 1-7 with binary reading of numbers in pattern 0.

    #8
X BGET P P.I I
IF X: $ + 1 I

  3. For simplicity I will often have scripts 1-4 controlling triggers 1-4, usually with one trigger controlling a bass drum, one a high hat, and two going to two inputs on a sampler. Heres what it might look like (Sometimes I have TR.P 4 controlled by metro as like a base clock to send to just friends or the samplers grain sync. Then script 4-7 control CV sequencing.)

    #1
TR.P 1

#2
TR.P 2
DEL CHAOS: TR.P 2 (just for fun random hihats)

#3
TR.P 3

#4
TR.P 4

#P0
9 (bass drum + sample 2)
0
2 (hihat)
0
1 (bd)
4 (sample 1)
2 (hh)
4 (sample 1)

  4. Lastly I’ll use the CV outs or i2c to control melody. Using P0 I’ll trigger scripts 5-7 which will advance patterns 1-3. I feel like I may be getting too in the weeds now because even the stuff I wrote just above ^^ is beyond my “base scene”. Once muting gets working properly (Alt-F1, for example, so that it muted from internal triggering as well as external—hopefully on the next teletype update, fingers crossed) then I may leave some of this prewritten, we’ll see. I also have toyed with using AllFlesh to manually trigger scenes 4-7 to get the melodies more off the grid, but I have had no success with this—it seems like it will acknowledge triggers from elsewhere over the bridged connection, but I can’t turn a high gate into triggers by tapping, perhaps even my fastest taps are too long of a gate (although with Just Friends sending triggers it seems like my teletype normally acknowledges two triggers—gate high and gate low—so I’m still a bit puzzled).

  5. Further possibilities: I haven’t had JF hooked up to i2c recently, but the possibility of using binary to control Just Friends in Geode mode or even just to control the triggering of envelopes instead of just triggers has certainly crossed my mind and I may be exploring this in the near future. Multiple bitwise/binary patterns maybe? With something like that, trigger outputs would be freed up for other uses… Basically any deeper i2c control I have yet to really incorporate into this scheme, I have some w/s which may get involved here too…

I hope this seems helpful and on topic to someone :stuck_out_tongue: As you can tell I’m still working on this, and it’s developing alongside my experiments with a Ciani inspired permanent patch which I’ve written about already a couple of places. Part of the appeal of a base patch is also that I will always know — CV 1 controls the bassdrum voice on Mangrove 1, CV 2 and 3 are controlling Mangrove 2. X triggers are doing Y, param is tempo. In building an instrument (which is my goal) I want to easily decipher what the brain is doing at any given time in order to be able to perform using only the teletype keyboard and some knob turning.

PS since writing this draft a couple months ago this thread on acid has made me want to do a version of this base script using binary ops to patch up a little acid machine—a four voice drum machine with some mod channels where you can slowly change individual steps over time… it seems like a perfect job for teletype, and I’m sure there’s more complicated and sophisticated ways to do it, but keeping it simple appeals to me… :slight_smile:

16 Likes
#17

this is great, and please feel free to post here - it’s an open topic / discussion!

your scene in a way is the essence of teletype - it’s a device that orchestrates events based on triggers, but unlike conventional sequencers, instead of just generating a CV/gate you can have more complex logic being executed on each step.

an alternative way to set up this kind of a scene is to just trigger all scripts on each metro but then use something like PROB or EVERY to control individual script execution. the benefit of doing it your way is being able to control all 8 scripts from a single pattern value (a fun thing to do would be generating random pattern values).

why this kind of a scene is great is because you can do many things in each script. you could add ratcheting by doing something like DEL.R 4 / M 4: TR.P 1. or add a simple CV 4 RND V 10 and then use it to modulate a filter or a delay, so you have a sample&hold that will change CV 4 value each time a drum is triggered.

re: allflesh not triggering teletype - you can use gates to trigger scripts, likely it’s just not hitting the threshold.

5 Likes
#18

Thank you, fantastic!
Two main take aways for me:

  1. Should use the param knob more!
  2. Should learn Bitwise OPs!

The way you store the sequence with multiple scripts triggered per step is just genius!!

5 Likes
#19

Same here! Gonna dive into Bitwise ops! Thanks for your post!

1 Like
#20

omg insane system really diggin it ! :heart_eyes:

#21

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

2 Likes
#24

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.

Screenshot_20210119-171322
Screenshot_20210119-1713221080×1537 349 KB

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.

9 Likes
#25

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.

2 Likes
#26

!!!

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.

2 Likes
#27

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.

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

should be fine!

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.

1 Like
#28

“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 :slight_smile:

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?

1 Like
#29

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.

2 Likes