#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
#229

Ah right. Yeah those OPs will be a breeze. 2.1 features are frozen, but those can fit in the next release (along with Turtle!) unless @tehn wants me to squeeze a few more into the beta.

… Too much time on my hands!

#230

it shouldn’t be too much trouble to test a few extra ops for the 2.1 beta (i mean, if you’re on fire).

1 Like
#231

Depends how long you want space minor releases apart. 1 month? 3?

#232

1 month is fine. updating is the users’ decision. what’s most important for user experience is good testing and documentation.

i’d like to get the screen glitches out by 2.1, so that will be something i look at over the next week. both @sam and @scanner_darkly have already posted good information to get this problem fixed.

the sooner we can get to 3.0 the better-- but usb file management and the timeline feature will be a more substantial untertaking.

6 Likes
#233

i think behaviour should be consistent regardless of where it’s used (and this should be the case for everything else). if we define something to mean “use the previous value” every op should support that, which is just not feasible (and would require every future op to support this as wel).

i do like the idea though, and a possible alternative would be to explicitly provide an op to set default values, so then this becomes “use the default value in its place”, and it would only be supported for those ops that have a way to set these default values.

or perhaps it’s best to just have 2 additional ops, one to set default values and one to use them. so, something like SCALE.DD 0 16374 0 16 to set and then SCALE.D X to use it.

this really makes me wish teletype supported op overloads for different number of parameters… but not sure if it’s doable with the existing code.

#234

i also have reservations about the $ op. it adds a sort of new complexity that’s not present currently and this should be long-considered before added. agreed that it should have universality, and that just doesn’t seem practical.

tt syntax does not lend itself to overloaded functions unfortunately.

i think THIS should stay as our original thought-- just whatever script it’s called from. i’m good with also having a keyword for whichever-script-was-most-recently-called: which should for all practicality be called LAST perhaps. and then perhaps we should revert back to my original command INPUT.TIME for time elapsed since input, or maybe SINCE

the “all” script is interesting, but i think it’s a somewhat narrow use case that could eventually be better served with the timeline.

our goal should be the fewest operators/functions with the greatest range of utility.

3 Likes
#235

Do you think we should have an operator for the current SCENE number, too?

#236

and an op for the last trigger executed - i think this would still be useful outside of ANY script (and would allow ANY script functionality to be replicated with a fast metro script)

#237

I actually thought SCENE acted as a getter already, but looking at the docs it doesn’t. It’s not clearly a ‘variable’ as you’re not truly editing that SCENE (but a copy of it), but i think it loosely makes sense

SCENE ADD 1 SCENE

Looks weird for sure, but intuitively I would say this should launch the next numerical SCENE. No new word added & the only logical ‘get’ for SCENE would be to return the current SCENE.

//

<edit: apparently this is not what LAST does!>

Then looking at SCRIPT. Can we think of SCRIPT as a variable that can be gotten? If so, would this be:

  1. The most recently executed SCRIPT (LAST); or
  2. The script from which it was called (THIS)

Are these two options not the same? If LAST is something different, it should be made clear that which script it refers to isn’t updated until the given script is completed. This could get very confusing if using scripts that call other scripts…

So, maybe we don’t need THIS, instead use SCRIPT SCRIPT for recursion, or STATE SCRIPT would return the trigger high/low state of the executing script.

And perhaps LAST (as in the last executed script) needs to be sketched out as an alpha feature – it’s the kind of feature that I think needs real world use, not just a does it pass the tests mentality. Perhaps it should only follow physical trigger inputs, or perhaps not. I would like to see people using it IRL to know what the most useful implementation is.

#238

LAST is currently an operator that indicates the time since a script was last called.

#239

Apologies if the terminology is wrong. However, I understood that functionality (most recently executed script) was mentioned at some point?! Not sure - there’s been so much discussion lately I can’t reliably keep up.

My point remains that SCRIPT and SCENE could have getters. This may denecessitate THIS.

2 Likes
#240

I like SCENE SCENE and SCRIPT SCRIPT as a replacement for THIS. :+1:

1 Like
#241

Re: Turtle

Friction? Acceleration? Gravity?

Edit:
I was thinking about adding a @BOUNCETURN operator that alters @BOUNCE mode to rotate some number of degrees before “reflecting” whenever it hits a wall.

It definitely needs a better name, tough.

The syntax that is currently in the beta:

@ get/set
@X and @Y get/set
@POS x y
@HOME x y (with no getters)
@FENCE x1 y1 x2 y2
@BOUNCE, @BUMP, and @WRAP
@DIR (degrees)
@SPEED (cells)
@STEP forward at the current speed + direction
@FWD x and @REV x
@TURN 
@UP x, @DOWN x, @LEFT x, @RIGHT x

Some trivial operators are missing because they are derivatives of this functionality, e.g.: individual fence variable setters. Notable exceptions include @FENCE and @HOME getters.

#242

Hah! Good point. I meant it more as an experiment for the curious, not as a vote against the operator. I’ll use the operator quite frequently, actually. What’s Q21.10?

Some questions regarding turtle behavior before I test it tonight or tomorrow:

  • How does DIR behave with various degree settings? If I have it set to 45, I’m imagining that a STEP command will move it one step diagonally on the grid. If I have it set to something like 10, will it continue forward and eventually make a diagonal step, or will it interpolate between values?
  • How would the proposed Friction and Acceleration work? Would they just increase/decrease SPEED behind the scenes? Would that get quickly out of hand?
  • If I don’t supply an x argument to FWD, does it use the current SPEED or does it step by 1? What about the UP, DOWN, etc. operators? If FWD without arguments uses the current SPEED, then how does it differ from STEP?
  • Idea for a command: @UNDO. It would return the turtle to its previous cell. Whether or not it should keep any SPEED or DIR updates since that move could be discussed.

Thanks again for all of your contributions so far. Since you first mentioned turtle the other day, I’ve found myself thinking of Scene ideas at random idle moments.

1 Like
#243

Signed fixed-point integers with 22 bits to the left of the decimal place and 10 bits to the right.

The position is tracked internally to a 1/512th fraction (which by chance is Q6.9 :wink: ), then rounded up at resolution time. Setting a 45 degree angle with 1 speed will move 0.707 units of distance per step edit:in each axis.

Friction would decrease speed over time and acceleration the opposite. New operators would spawn to auto-step (i.e.: apply friction and acceleration) and stop (not do so).

Use STEP to advance by 1 unit of SPEED.
Use FWD and REV to to advance / retreat by X units of SPEED.

@UNDO would require some memory for the stack, but it’s doable, and I think a good idea. :+1:

No problem! I really l like coding and I put teletype in my 104hp system, so I intend to put it to good use.

I can’t wait to see your scenes!

#244

Thanks for the fast reply! My one thought is that calling FWD or REV without an input argument would just default to using the current SPEED. That would remove the need for the STEP operator and would save one character. Plus, FWD SPEED and STEP have the same outcome, but REV SPEED doesn’t have a single-op counterpart.

#245

Teletype syntax does not support multi-arguments-length operators (I don’t think… @tehn / @sam / @scanner_darkly ? ).

Good point, maybe @BACK?