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

#246

I can see the inner logic of this but I find it unintuitive when the turtle does not move on every step. Especially when the grid and its resolution is not that big.

I think a step by step behaviour would be much better/more intuitive. So that the turtle moves one step diagonally with 45 degrees and speed 1.

Does SPEED just mean that single steps are skipped at higher speed or that you would need more STEP commands to get a movement at lower speed? Or is there some kind of autonomous movement running, leaving the event character of teletype as the metronome does?

I wonder if it would not be reasonable if the fix of the screen glitch issue wouldn’t be combined with too many new features to keep it safe and not having it introducing more new bugs again that are hard to track down due to the number of changes made and due to the resources available. We would have a secure base then to start from and no user would be forced to upgrade to a more complex environment just for having the basic functionality working smoothly.

I still have a feeling that the actual development process is pretty fast and mixes brainstorming with development, going back and forth. The discussion about it seems to go fast as well and is between a few highly skilled members of this forum. I hope that there will be a point where all exciting new ideas will get bundled and cut down to a reasonable feature set and teletype won’t loose its immediacy.

2 Likes
#247

I don’t know… One of the benefits of carrying the remainder over is that something like 170 degrees make sense: You iterate mostly down, but sometimes you shift a cell to the right.

If every step were consistent in both axes, there’d be less potential for long-term evolution of the turtle’s position.

I’m curious what other people think. (Plus I already wrangled sin() in there with great effort and I’d hate for it to go to waste.)

Re: Friction and acceleration

In short, yes there would be updates of the turtle’s position through time if (say,) @GO were called. These updates would cease if (say,) @STOP were called.

I agree about pruning the turtle operators. There’s some overlap, so which stays should be carefully considered.

On that, maybe there should be a @GOSCRIPT that executes a script whenever it steps on a new cell in @GO mode.

1 Like
#248

Sounds pretty good to me :slight_smile:

2 Likes
#249

Although this does highlight that maybe SPEED should have a fractional component, too. Maybe

@SPEED numerator denominator

Where @SPEED 1 1 would result in 1 and speed 707 1000 would be 0.707

#250

I can follow this logic but still wonder if it is guaranteed that the turtle will actually move a step when a STEP or FORWARD command is given. I am not good in maths but it seems that two steps in a 45 degree direction will be rounded to one step, or am I mistaken here?

Also is there a bigger matrix now for the turtle than the tracker mode? So that long term evolution would make sense?

#251

It is not guaranteed that @STEP results in the turtle moving from one cell to another right now. I can appreciate how this behaviour might be undesirable.

Maybe @STEP should advance the position to the point where the cell changes, but then @SPEED is basically invalid.

And no, the matrix is the tracker, 4x64, and I think that @tehn wants that.

Yes, 2 steps at 45 degrees = 2 * 0.707 = 1.414 in each axis.

#252

I think I would not want to have another matrix screen/mode on tt either as I would be afraid of cluttering the interface (there is still the TL coming…).

When I think back to the René I had before Monome the 4 x 4 matrix was pretty nice and now being able to shift it over 64 lines seems great eough. It’s that what had me thinking if those long term evolutions you would get with for example 170 degree turns actually make that much sense compared to the behavior of actually not making a step forward when it is asked to.

#253

I guess what I said was ambiguous. @tehn has stated (I think) that he does not wish for a different matrix for the turtle.

If we ever double the patterns, I could see the turtle moving between them at the edge where they meet.

I guess turtle could also have a “square” mode where it cuts up the patterns into a 16x16 grid but that would be confusing, I think

#254

if there is a clear user interface proposition for a turtle-matrix and how that would be transposed onto the pattern matrix, i’m up for suggestions-- users should weigh in.

#255

Maybe it would be neat if the turtle could carry around a number to do stuff with. Example:

@PICK  // copies the current position to the carry position
@PUT   // puts a copy of the carried number in the current position
@SWAP  // swaps the carried number with the current position
@CARRY // get/set the carried number

I guess PICK / PUT could be PEEK / POKE, too. Or maybe COPY / PASTE.

1 Like