#209

Thanks!

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.

1 Like
#210

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)
#211

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!

3 Likes
#212

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.

#213

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.

1 Like
#214

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:

SCRIPT $
LAST $

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)
#215

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

3 Likes
#216

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

2 Likes
#217

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:

  • CHAOS
  • P.MAP and IN.MAP
  • EVERY
  • 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.

1 Like
#218

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.

#219

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

1 Like
#220

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.

#221

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.

1 Like
#222

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.

#223

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.

#224

I have very fond memories of Turtle Graphics on the BBC Micro in junior school, but… I’m feeling like the turtle may be too constrained only operating within a grid of 64x4.

Now even if we add an extra 4 patterns, it’s still only 64x8.

How about a separate transient1 grid for it, then it could be 64x64.

We could have some OPs for copying sections to and from the patterns if needed. Or if you’re really keen a visual editor.

1 By transient I mean one that is not saved with the scene, but also one that survives scene changes, i.e. it behaves as the variables do.

Also should we hack the font table to draw a turtle instead of an @?

:turtle:

1 Like
#225

Please not - also as I have a feeling that teletype is exploding feature wise I really wish someone would undertake the task of fixing the screen glitches/lost lines first.

Seeing that there are a lot of modes approaching I dare to bring back the changed mode switching behaviour of v2.0 which I still find cumbersome. How are all those screens to be organized and accessed? A single key to switch between TL, turtle mode, edit mode, live mode, tracker mode and the not yet imagined mode does not feel appropriate for this task think.

#226

Okay…

Here is a list of OPs that I wish I had the time to implement, so if you wanted to do any of them, none of them should take very long to do…

  • TER a b c (alias ?), ternary operator. If a > 0 return b, otherwise return c. You need to add a warning to the docs to indicate that this is not short circuiting, so both b and c will be evaluated (e.g. could be a problem with P.RM).

  • P.INIT / PN.INIT initialise a pattern to the same as power on conditions. Maybe a PA.INIT, PA stands for all patterns.

  • INIT.VARS initialise all the variables to power on conditions (e.g. A = 1, B = 2, etc, etc). Should be easy to code as there are already functions to initialise scene_state_t.

  • INIT.ALL reset everything (apart from script contents) to power on conditions. (e.g. so all the patterns, all the vars, also metro values, etc). I suspect this will end up being the first command in everyones I script.

4 Likes
#227

Curious as to why you would call it in I, to reset the patch? Why not just SCENE current?

E: turtle is written, testing it this afternoon. :slight_smile:

1 Like
#228

The contents of variables persist between scene changes.

Likewise, trigger lengths, CV offsets, stack and delay contents, etc, etc. It’s possible that some of the pattern variables persist too (P.N?).

So by calling INIT.ALL as the first line of your I script you can bring the Teletype into a deterministic state.

2 Likes