Thanks for the fast reply! My one thought is that calling
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.
Thanks for the fast reply! My one thought is that calling
Good point, maybe
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.
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
Sounds pretty good to me
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
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?
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.
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.
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
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.
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.
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.
I see it as a dedicated variable. There’s nothing that you can do with these that you can’t do elsewise, I agree.
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.
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.
- 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.
- 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.
- 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.
- This shortens the number of characters needed for all deterministic single steps.
- This provides a quick way to do a deterministic diagonal step.
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.
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.
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.
got it. perhaps it’s time for a repost of all the turtle ops? those confirmed and those for consideration?
I will keep this post up-to-date as decisions are made.
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
@BACK (counterpart to @STEP)
@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)
- 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
@HOMEbe both a 2-argument setter and a 0 argument command, I don’t think.
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?