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

these are great ideas for functionality, but i think they’re so easily executed with existing commands that we should avoid adding these specific ops. of course i could be convinced with some compelling command comparisons and examples.

#257

I see it as a dedicated variable. There’s nothing that you can do with these that you can’t do elsewise, I agree.

That said, I has lost its status as a general purpose variable, so technically, users are down 1. So there’s that.

I get the operator bloat concern, certainly.

edit: I’m just throwing out ideas here, I don’t have skin in the game on this one.

#258

I love the idea of using the Turtle to manipulate the grid instead of just reading values.

Regarding what @Leverkusen said, I’m in partial agreement regarding angles and intermediary positions. For me, feedback is everything. Instead of 360 degrees of turtley freedom, I think I would just want 8 directions of motion.

  1. You were mentioning rotating the top-down turtle glyph to show which way the turtle is pointing. This can work with 8 directions, but anything more granular wouldn’t work.
  2. Take the 45 degree example. You said that the turtle would move 0.707 units in each axis. For me, this complicates the diagonal step, which I think should be more straightforward. I feel like I could get easily lost with these fractional steps, and there wouldn’t be a high-resolution display showing exactly where the turtle is.
  3. On the flip-side, this provides a great way to generate wandering melodies when you don’t quite care how long the turtle takes to get to the next rock in the stream.

One idea for a compromise: Keep almost everything the way it currently is. However, replace @UP @DOWN @LEFT @RIGHT with @N @S @E @W. Also add in @NE, @SE, @SW, @NW.

  1. This shortens the number of characters needed for all deterministic single steps.
  2. This provides a quick way to do a deterministic diagonal step. @NE replaces @UP;@RIGHT.

The 360 degree option could stay and provide a more unpredictable, generative experience. This would just provide a simpler option for quicker paths.

Side note: There should probably by a @RESET op that would reset the turtle to its home position, set the SPEED to 1, and return to its initial direction.

#259

i think this was always the idea:

@ would return the value at current position
@ X would write the var x to the current position

this is a good compromise.

just to clarify: @N for example moves the turtle north and also returns the value, correct? it’s a move-then-read?

not sure we need @RESET = @HOME; @SPEED 1; @DIR 0

let’s try to aim for less ops, which will mean less memorization.

#260

None of the move ops currently return the stepped-on value. @ must be called separately. This allows moves to be chained without leaving garbage on the command state stack.

#261

got it. perhaps it’s time for a repost of all the turtle ops? those confirmed and those for consideration?

#262

Turtle Specifications

I will keep this post up-to-date as decisions are made.

Implemented:

Parameters:
@SPEED, @DIR, @HOME, @FENCE, @X, @Y, @POS, @,
@FX1, @FY1, @FX2, @FY2, @HX, @HY
Movement Modes:
@BUMP @WRAP @BOUNCE
Movement:
@N, @S, @E, @W, @TURN, @STEP, @FWD, @REV, @HOME

Planned:

@BACK                   (counterpart to @STEP)

Proposed

@UNDO stack
@ACCEL, @FRIC, @GO, @STOP (automatic movement)
@GOSCRIPT                 (script to call when cell position changes)
@SPEED N D                (numerator / denominator)
@COPY, @PASTE, @SWAP      (internal storage)
@BOUNCETURN               (turn x degrees after hitting wall but before going forward)

Behaviour questions:

  • When a user adjusts a fence, should it follow BUMP logic or the current mode? i.e.: can you “swat” the turtle with the fence or do you just keep him in bounds?
  • More to come, I’m sure

Problems with operators:

  • I can’t make @HOME be both a 2-argument setter and a 0 argument command, I don’t think.
1 Like
#263

I have to admit that I cannot follow the process - so the feature set of yesterday is not relevant anymore?

Also I do not understand the difference between @STEP, @FWD and @GO.

Does @HOME (getter) mean it outputs the home coordinates or that it gets the turtle there?

What is the meaning of @HOMEX and @HOMEY?

What is the meaning of @N, @NE, etc.?

Regarding @BOUNCETURN - does @BOUNCE already mirror the angle in a physical meaningful way?

I don’t know if there is really a need to change all possible parameters. It might feel good to have all opportunities in the world but wouldn’t this just lead to some indiscernible variations of randomness in practice at the cost of a more complex operator set.

I think it should follow the current mode - if you want to stop the turtle you can just stop it, can’t you?

#264

how about @MODE X to turn turtle on/off and set standard fence sizes with values 1-n (4x4, 4x8, 4x16 etc). @MODE 0 would stop executing all turtle OPs.
the tracker should indicate then where the borders are, maybe with small brackets at the corners.

#265

The lists are the same, though?

STEP - move forward in DIR for SPEED cells
FWD - move forward in DIR for X cells
GO - auto-step (feature not fleshed out)

HOME currently goes to the home position. It was slated to be a 2 argument setter HOME X Y, but now there’s HX and HY.

N - step X cells “north” (0 degrees)
NE - step X cells “northeast” (45 degrees)
etc. - the remainder of the cardinal and diagonal directions.

No, right now the direction does not change when you bounce off the fence. I suppose it could alter it 180 degrees by default, but hadn’t considered this when I first wrote it.

If there’s a parameter that you feel is excessive, point it out so we can discuss it.

I’m not talking about GO or auto-step or even STEP. Consider:

@WRAP
@FENCE 0 0 0 2
@Y 2
@FENCE 0 0 0 1

What I’m asking is “should the position adjustment after the second fence command simply corral the turtle into the fenced area (@Y = 1), or should the current mode apply (@Y = 0)?”

I can’t say that I like this idea.