Teletype 3.0



I spent a lot of time with 2.3 RC 3 yesterday. Everything I tried worked as expected. Let me say again how utterly fantastic and cool all of the 2.3 additions are and again express my thanks to all the contributors!

The only thing I’m noticing is that there still seems to be something funny related to hot connecting the grid to teletype. I haven’t repeated what I encountered earlier, which was the teletype completely freezing. But maybe 1 out of every 15 times when I disconnected the grid now, the teletype seems to slow way down. Power cycle brings it back to normal. Also possible that it’s something about my script, which I’ve now posted in grid exchange thread.


could you describe in more details what happens when you experience the slow down? can you still connect keyboard / switch between pages / edit scripts? also, when it happens do you have the grid control mode on?


Other than the first time I experienced this (which was RC1), yes, I can still connect the keyboard, switch pages, write the scene to flash, etc. Switching pages is a bit more sluggish. By slows down I mean this scene I was using is clocking things and I can hear the tempo slow down/stutter, as though the CPU is overloaded. (Not saying CPU overload is actually happening, I have no idea, that’s just what it seems like).

No I don’t think grid control mode has been on when this happened that I can remember.


if you run into this scenario again, could you try manually executing G.RST from the live screen and then the init script and see if that fixes the slow down without rebooting? (it’ll wipe out your current button/fader state, so you might want to save before you do this).

when it happens, does it gradually get slower, or does the speed just drops when you disconnect the grid?


I’ll definitely try that. The slowdown is immediate/all at once. And since RC3, disconnecting the grid seems to be what triggers it.


so, in regards to the issue of scaling a fader value. the reason here is two fold.

first, G.FDR.V is calculated by dividing the full range (which is by default 0…16383 but you can change it with G.GFDR.RN op) by the number of steps available for that fader. when that calculation is made it doesn’t round the result, it just discards the fractional part.

second, when you apply SCALE to that there is additional loss of precision.

both of these contribute to what you’re seeing, and both will need to be fixed to round properly and not lose precision. not sure if the fix will make it to 2.3, but i’ll add it to my list. funnily enough, i just ran some calculations, and if i only fix G.FDR.V without fixing SCALE the result will be even worse: you’ll get 0, 2, 2, 4, 4, 6.

there is already a workaround though. if you want to use an 8 button long coarse fader to get values 0…7 just use G.FDR.N instead, it gives you the fader value in “buttons”. alternatively, if you set the fader range to 0…7 with G.GFDR.RN 0 0 7, G.FDR.V will also give you correct values in 0…7 range.


Thanks for the explanation. Makes good sense now.

In my case I was having trouble sparing the code lines to work G.GFDR.RN in. Looks like it sets it for an entire group which would work out well in a lot of cases, I think, except that in my case, most of the faders I was creating needed a different range. Referring to the scene “Pillar” that I posted, the note/gate tiles have 4 associated parameter faders.

Note scale 0-7
Gate probablity scale 0-99
Linger scale 1-8
Gate length scale 1-8

So I think it would have required more lines of code to first create them into their own groups and then set their ranges than it would have to just create them all at once with G.FDX and scale them on demand?


i see, yeah, in your case it might not be the ideal solution. for these specific ranges though you could set the range for all faders to 0…99 (so you wouldn’t have to use different groups) and then use G.FDR.V for gate probability, G.FDR.N for note scale and + 1 G.FDR.N for the rest.


Hadn’t thought of that. Great idea! I think that might actually free up some characters and possibly lines!


new release candidate. i wasn’t able to reproduce the slow down issue @EqualTemperament experienced but i’ve made a couple of changes that might help with the issue (if my guess as to what’s causing it is correct). this version also improves precision of SCALE and G.FDR.V ops (with the example @EqualTemperament posted above it will now return proper values without having to use the workaround).

release candidate 4 july 2nd
2.3 RC4


The TelexO TO.OSC.WAVE Op might need a documentation update in advance of the release.


Nevermind. @bpcmusic is on the case!


Hi! I just installed 2.3 last night so I’m taking a look at some of the new stuff. The new P.RND op seems cool. I began with a 4 step pattern that I was playing back with P.NEXT so I tried switching to P.RND and I found that it was choosing from all 64 steps (everything outside my 4 step pattern was 0).

So, the issue was that P.END was set to 63, which brings me around to a point of confusion I’ve always had with Teletype’s pattern tracker: the relationship between P.END and P.L. To me, it seems like it would be more intuitive if the two values effected one another… like if you set P.L, then it would automatically change P.END to be + P.START P.L. Not sure what the rationale is for how it currently functions, but in the case of P.RND not working with the same range of pattern values as P.NEXT, I think its confusing.

I’m also wondering if there are any keyboard controls for setting the loop start/end/length in the pattern tracker screen that I have overlooked. I didn’t see anything noted in the manual, but I kind of remember this being possible?

One last thing, this seems like it could be a bug, but I inadvertently discovered that in the pattern tracker view, when I hit CTRL, it changes the currently hovered cell to 6! Weird!


yeah, P.END vs P.L is confusing to me too. i think the intent was for length to be used when you do P.INS and P.RM, and for P.START and P.END to be used with P.NEXT and P.PREV, but then it wraps when it reaches either P.END or P.L.

we could change it so that setting one changes the other, but this would be a breaking change in behaviour so probably needs to be discussed in a separate thread before we consider changing it.

right now the behaviour is: when you execute P.NEXT it will advance by 1. if it reaches either P.L - 1 or P.NEXT it goes to P.START (link). this would need to be changed as well. also this means that P.RND does work with the same range as P.NEXT, as long as you set P.L to be greater than P.END.

straight from the source code - if somebody checked which ones are missing and modified the pattern doc file that’d be awesome:

    <down>: move down
    alt-<down>: move a page down
    <up>: move up
    alt-<up>: move a page up
    <left>: move left
    alt-<left>: move to the very left
    <right>: move right
    alt-<right>: move to the very right
    [: decrement by 1
    ]: increment by 1
    <backspace>: delete a digit
    shift-<backspace>: delete an entry, shift numbers up
    <enter>: commit edit, extend pattern length
    shift-<enter>: duplicate entry and shift downwards (increase length only
    if on the entry immediately after the current length)
    alt-x: cut value (n.b. ctrl-x not supported)
    alt-c: copy value (n.b. ctrl-c not supported)
    alt-v: paste value (n.b. ctrl-v not supported)
    shift-alt-v: insert value
    shift-l: set length to current position
    alt-l: go to current length entry
    shift-s: set start to current position
    alt-s: go to start entry
    shift-e: set end to current position
    alt-e: go to end entry
    -: negate value
    <space>: toggle non-zero to zero, and zero to 1
    0-9: numeric entry

there are 2 more shortcuts:

pressing ctrl will input the current knob value (scaled to 0…31) into the current cell, pressing shift-ctrl will do the same but scaled to 0…1023 iirc (i thought i changed ctrl to something else so that you don’t accidentally change pattern values while muting scripts but i’m not seeing it, i’ll change it to alt-ctrl).

Grid ops / integration

I’ll check the docs, since I’m in the neighborhood, so to speak


great, thank you! make sure to fetch the latest changes first, i had some new commits since your last PR (git fetch -all and then git merge).


… and it’s now a 100 commit branch


(no particular significance to the number other than indicating that it’s going to be a huge PR… which is not necessarily a good thing. but good to be getting close!)


as of my branch the docs match what you say. I can add the two other shortcuts if they’re not there when I fetch.


i can add those, that’s a small change.

@freqout which doc did you use to check the pattern shortcuts? - this one? want to make sure there aren’t any other places where we have outdated info.


this is where i ended up looking… forgot there was a key-specific doc…