(Teletype) Pre-2.1 Operators and Features


The turtle idea is great - I remember using logo back in the day. I was also recently thinking of ways to use the pattern page to emulate the Kilpatrick Pattern Generator and there it is.

Also, I think now is the time to raise this … PONG!



turtle would be absolutely terrific!


i do like turtle.

it’s important to acknowledge that the feature increase will be overwhelming to new users, but i really think this can be mitigated by well-sorted documentation. i’d sort turtle (as well as ER, JI, and some others) into a “specialized” category (perhaps there’s a better word, but “advanced” is not correct).

this way the introduction can unfold methodically as it does now, introducing new capabilities-- and then there can be almost an addendum series of specialized op’s/etc.

also to clarify turtle:

@ is the same as P.N @.X @.Y correct?

to SET a value (x) at turtle position: P.N @.X @.Y X

so could we use @ X as “set at position” like above?

is @.HOME 0,0?



By default? Yes. I used 1 above for the example because I forgot that patterns and pattern data were 0-indexed :wink:

Yup. North (up) is 0. @.DIR default would be 180.

I think everyone knows how a circle works, but we could add some aliases for the cardinal directions if anyone thinks that it’s needed. NORTH, SOUTH, EAST, WEST maybe? For that matter we could have LEFT, RIGHT, and AROUND for relative positioning. I personally am fine without these.

I used @. with the period for everything, but I’d be more than glad to drop it. Save a character, and because @ is so notable, there won’t be any namespace conflicts. @HOME, @DIR, @SHOW etc.


this turtle business is awesome! kudos for everything, @sliderule!



Aside: We need more people to put the 2.1 through the ringer. I’m happy to have the beta period last a long time, but only if it’s getting tested! I’d hate to release it after a few weeks only to find bugs then because it hadn’t been well-tested enough.

FYI: beta2 has no known functional bugs or crashing, but your complex, but everyday script might find one! I’m particularly looking for testers with other monome gear connected over i2c to ensure that complex setups are unaffected.


Another thought: should the Turtle’s state persist across scene loads?

Also, the Turtle needs a fence.

@.MAXX 1 (default: 3)
@.MAXY 12 (default: 63)
@.MINX 0
@.MINY 0
@.FENCE X1 Y1 X2 Y2 (set all at once)


do other variables change state in between scene loads? patterns do. i’d be compelled to treat @ like every other variable.

i’d opt against these, they seem excessive

i think that also sounds good, omit the period.

agreed re: fence, looks good

i’ll push on 2.1beta2 today and tomorrow!


Yeah I did light beta 2 testing last night. Didn’t test any new features, but just loaded some of my existing Scenes without issue. I’m very excited to dive into the new stuff, though.

@HOME should also have a setter (@HOME X) so that we can treat it like a variable reset position. If HOME is outside of the FENCE, I imagine that it should default to the top-left of the fence. Likewise, MAX/MIN X/Y should have getters that return their values if no arguments are given.

For safety, if MAXX/Y is below MINX/Y, then they should basically exchange values behind the scenes.


Agreed on all counts. The language described above had some omissions in usage for brevity, but any getters listed that could logically be setters will be get/set.


The syntax of multi-set type operators could be improved by creating a token that means “don’t alter this value”. For lack of a better thought in my head, here’s what I mean using $ as the operator:

@FENCE $ $ 1 24

This would prevent me from having to implement 4 other operators. $ could evaluate to 0 for nonsensical contexts but be identifiable by the command state.

$ could also be used as a “special argument” to other things, like SCRIPT and LAST. We had to add THIS to refer to the current script for just those two operators, but they could have also been implemented as:


Just a thought…

Edit: Expanding upon this, there could be delta operators to modify parameters:

@FENCE $+ 1 $/ 2 $ $ (shrink the fence by one column and half the rows from the top left)


I think if HOME is outside the FENCE, the values should be clamped to the nearest extent of the FENCE. Defaulting to top-left means that if you shrink the FENCE, the turtle’s behaviour changes drastically.

Edit: I haven’t addressed those expressing gratitude, so I’ll rectify that here: You’re welcome! I’m so glad that my participation and effort is appreciated.

:heart: teletype community


wanted to bump CHAOS as some more sophisticated indeterminacy would be welcome


I’ll add it to 2.2 or whatever branch comes after 2.1 drops. I’ve got a little research to do to make sure it’s as varied, flexible, and powerful as possible.

For that matter, here are the outstanding operators:

  • P.MAP and IN.MAP
  • R
  • F
  • @

And Features:

  • Unified scheduler for M / DEL / R
  • USB filesystem / scene UI overhaul
  • Dynamic allocation of DEL, STACK, Q, exec_state, etc.
  • Tracker visualization modes (bars)

I’m sure I’ll edit more in later as I remember them.


There are so many varieties to choose from! A good place to start are the chaos generators in SuperCollider:

The Logistic map listed in the Noise uGens is also great:

One of the distinguishing design issues with a CHAOS operator is that there should be at least one exposed parameter so that the user can control how chaotic the system is. One idea would be that CHAOS X sets the chaos generator’s parameter (and maybe simultaneously returns) while CHAOS just returns the next iteration. Most chaotic equations can return outputs in multiple dimensions, so it’s worth considering CHAOS.X to return the current X and CHAOS.Y to return the current Y. That would probably complicate things too much.

My vote is for a single parameter chaos generator. Good candidates:

  • Ikeda Map: 0 when its parameter is 0. Stable triangle-ish oscillations as the parameter increases and then a total breakdown.
  • Logistic Map: My personal favorite. Stable triangle oscillation at a neutral parameter setting with a very smooth transition between stability and chaos. It has the advantage of being very computationally simple. It also only has one dimension, which simplifies the design.
  • Standard Map: A lot of fun. It doesn’t have as many stable regions, but it can occasionally get caught in a cycle when tweaking the chaos parameter.
  • Tent Map: Unipolar. X out is flat when the parameter is 0. This ends up looking like a lot of triangles with various speeds and amplitudes.

EDIT: As a side note, I think the Logistic map is what’s used in the Batumi expert firmware. It is also used in Ornaments + Crimes.

EDIT 2: The Logistic map is so simple, you can already program it as a Teletype script without the need for an operator.


But I can do it in 32-bit math internally, and with much better behaviour.

Edit: plus, who doesn’t love working with fixed-point math? (Also I already wrote the logistic map in Q21.10 so I can just port that one.)


would be great to have a one character alias for THIS ($ could be a good option if it doesn’t get taken for anything else).

what about an additional script that would be executed whenever any of the triggers is fired, together with a variable that would store the number of the last received trigger? this would help with those scenes that have essentially the same script repeated for each trigger.


Did you see this idea? What do you think of that kind of a token?

An ANY script, essentially? THIS could report the trigger number in the ANY script, eliminating the need for another operator.

Edit: How about allowing any of the scripts to be an ANY script with a toggle, being processed in order? It’s an interesting solution to the script limitations. It essentially saves you from having to write SCRIPT (next) at the end of one script, saving an entire command.

It’s a radical idea and it flies in the face of the at-a-glance ethos, so it’s not great.


yeah i saw that, it’s an interesting idea but not sure how it would apply consistently to all ops. wouldn’t that mean that each op would need to maintain a state? or would it only apply to certain ops?

yeah, ANY or ALL script essentially! not sure about switching scripts 1-8 to be ANY, this could get confusing (and if we’re talking radical why not a full 8x8 matrix of which triggers fire which scripts :). but a simple A script would be very useful, you could use conditions to change which triggers it reacts to (and you could use variables for that). regardless, i’m thinking a variable to store the last trigger would come in handy for other purposes too, and i would use a different name, not THIS, so it could be used in other places too.


Yeah I can see how the simpler solution is the better one.

As to the $ token idea, it would be a special argument that would have different meaning in different operators. It evaluates to 0 everywhere else. The state would be stored in command_state_t.