#268

Hm, maybe @SET.HOME then?

So it would be the same as BUMP just ending on a different position. I think automatically altering the angle would make more sense.

Considering we have a grid that is 4 columns wide I don’t see interpolating operators like SPEED and DEGREE making much sense.

When you move on the East/West Axis with a speed higher than 1 or an slightly off angle you would just get a pseudo random behavior and this can be reached otherwise. There are no steps possible greater then 3 and it would not be vaguely predictable where the turtle would go in such a small space when it constantly bounces back from a fence.

It would just make the operator set more complex without giving a substantial gain. I think if you want a slightly evolving variation on the North/South Axis you can easily get this by simply adding or substracting offset to the read value or to the position by using @POS.

Also if you want it to autorun why not put it in a Metro script or using the upcoming autotrigger feature?

I like the idea of the turtle very much though and I am a bit excited about it too. Nevertheless I think it makes the most sense to keep it simple so it would work nicely in 4 x 4 grid. You could still make it longer, up to 4 x 64 following the sam principles. I imagine that a 4 x 4 grid moving through the tracker view while the turtle is moving around in it would be very nice. (So yes - moving the fences should somehow get keep the turtle inside or get it back in in sophisticated way)

Another point to consider is the sprite. I would prefer to see the actual value highlighted as it is now in tracker view. Of course a turtle is very cute but it would obscure the actual value and I don’t see any use in it.

#269

I guess we differ in opinion on this point. I’ve been making scripts that put the arbitrary angle and its effects to good effect.

Because you can precompute when the step will change using calculus and then delay exactly that long (this is not a fixed value when considering ACCEL / FRIC / GRAV), update its position, and then run the GOSCRIPT. If anything, you’d use DEL.

If you want it to work in a 4x4 grid, @FENCE 0 0 3 3. I don’t understand the limitations that you’re trying to place on navigating the tracker, or the complexity that you think using the whole pattern by default adds.

So two highlights showing, then? The one the turtle is on and the one you’re selecting? I don’t see how that’s clear to the user. A couple of points:

  • The turtle needs to be switched on to be seen
  • The turtle can flash on and off to show the value half the time
  • Seeing the turtle is very useful for observing the behaviour of the script

Edit:

Yes, the fence is already enforced. The only question is, when you alter the fence, do you “corral” the turtle in, or can you “swat” at it when using BOUNCE or WRAP?

#270

ATM active cells in a pattern are mildly highlighted, the current editable cell is bright highlighted and the current active step in each column has a marker, non active cells are dim. Four different and non obscuring highlights and II find this very clear but I also see the use in spotting the current direction.

I don’t understand this - “swatting” as in “beating to death”? I guess “corralling” is the behavior I would prefer.

Don’t understand this either. You are honestly pre-calculating when the turtle will be on each individual point to get your scripts triggered at the right moment? I think I understand how different our approaches are now and why this seems far too complex to me.

#271

An example:

@WRAP; @Y 4; @FY2 3
A @Y
@Y 3; @BOUNCE; @FY 2
B @Y
  • Corral: A = 3, B = 2
  • Swat: A = 0, B = 1

I am not doing that yet, but it will be a requirement for GOSCRIPT, and is entirely feasible, don’t worry.

The behaviour plays out like this:

  • In auto-step mode, @ moves at the current SPEED.
  • Whenever you call @ you get the value under where you’re standing.
  • If you set GOSCRIPT 1, then script 1 will automatically run when the turtle crosses a cell boundary.
    This may have varying periodicity, and hence is completely different from reading @ at a fixed interval.

edit: This behaviour is not in exclusion to the other behaviours of the turtle. You can move about however you like.

#272

Nope, I don’t get it - might be too much for me…:man_student:

I just hope the screen glitches will get fixed before all this is implemented in the official firmware - I will be happy then and stay with v.2.0.

:man_factory_worker:

1 Like
#273

in my opinion, this feature has grown to a level of complexity that is not entirely necessary for maximum flexibility.

please see my abridged command set proposition below:

primary

  • @ : get/set value at turtle position
  • @X and @Y : get/set turtle x/y position
  • @MOVE x y : set relative position (shortcut for @X ADD @X x; @Y ADD @Y y)

bounds

  • @FX1, @FY1, @FX2, @FY2 : get/set fence
  • @F x1 x2 y1 y2 : set fence (shortcut)

directional movement

  • @SPEED, @DIR - get/set speed (scaling needed, or assume x/100) and direction (0-359)
  • @FRICTION, @ACCEL - get/set (needs arbitrary scale, i’m fine with 0-100)
  • @STEP - execute speed @ direction (and apply FRICTION/ACCEL, respect fence)
  • @BUMP, @WRAP, @BOUNCE - get/set true/false, mutually exclusive
  • @SCRIPT - get/set which script gets executed on cell change (0=none)

as you can see, this is a substantial trimming down into a command set that i feel is memorable and also allows basically every feature listed in the longer version.

i’m not convinced there should be yet another timer for running the turtle on auto, but i’d possibly be up for that. something like @AUTO which is the exact same as running @STEP every 10ms or something.

please strongly consider the elegance of a more minimal set of ops-- it’ll be a much easier feature to get into as a result. imagine writing the tutorial to this set of ops. imagine how this op is towards the very end, and that it only needs to introduce a few new things and people can build on their existing familiarity with TT norms-- manipulating vars, basic math, etc.

8 Likes
(Teletype) 2.1 Firmware Beta (rc2: EVERY et al.)
#274

I never doubted that there’d be a culling stage after the brainstorming one. I throw out a lot of ideas on this complex feature so that what is required becomes evident. It helps to see the landscape to choose a path.

I’m glad that you were able to pare it down to the feature set that you want to see. I like the selection that you’ve come up with, and I agree that it represents all of the turtle’s functionality succinctly.

This would only come in after a new script-space scheduler is in place. I hope to overall reduce the number of interrupts firing, not increase them.

3 Likes
#275

The addition of new ops and features doesn’t mean you have to use them, and it shouldn’t change how you use current ops and features in any way. The addition of a more complex op like the Turtle (or whatever) shouldn’t preclude you from updating firmware and getting other improvements or features that you might use… there’s already a lot of stuff in TT that I don’t use on a regular basis, the fact that it’s there doesn’t impact me…

6 Likes
#276

I think this list is perfect, but my only request would be the @N, @S, @E, @W ops (no need even for the diagonal operators).

Compare @N to @MOVE -1 0 or @DIR 0; @STEP

#277

Outstanding questions:

  • Fence adjustment with now-OOB position: Corral or Swat?
  • Bounce behaviour: turn around on bounce?
#278

i see no problem writing out @MOVE 0 -1 instead of @N

these shortcuts are a slippery slope. they have to have a very strong advantage, not just shorter. BPM is a strong case for shortening as it also contains a magic number and is a very common use.

if you have a series of example scripts that really employ the cardinal directions i’d be happy to consider it further, but i’m attempting to reign this in while keeping functionality

probably corral.

bounce, i’d follow a physics model. are you talking about acceleration having it’s own direction vector? that seems too complicated at first thought. or perhaps i’m misunderstanding the question.

#279

I’m just talking simple reflection. Right now bounce hits the wall and bounces back but doesn’t rotate at all, so you’re still facing the wall. Presumably, you’d want to rotate 180? It’s just something that I didn’t think of the first time around.

#280

Maybe people are just different there but it in fact does impact me - even if it shouldn’t. The “you don’t have to use it” argument is not valid for me since I have to filter through everything anyway. And it does become more complex with an increasing manual and shed loads of operators and functions. The whole thing becomes less immediate when I have to think about which of several operators to move a turtle forwards might be the right one to use in a specific situation.

I don’t think that more options are always better than a well balanced system with clear constraints. Also the more complex a system gets the more it is likely to fail and the harder it is to maintain, for example to fix bugs. Also more features often lead to more desire.

In the end I would prefer fixing bugs and perhaps extend the current feature set a bit with more i2c integration for Ansible over fancy new features. I still like the turtle though and certainly the Timeline is interesting too.

1 Like
#281

The angle of reflection depends on the angle of incidence - when the turtle bounces diagonally rotating by 180 degree will not fit a physics model.

http://www.physicsclassroom.com/class/refln/Lesson-1/The-Law-of-Reflection

1 Like
#282

D’oh, I knew that. I was thinking about the head-on collision when I wrote that.

e: I mean, I wrote a bouncing lines screensaver like 25 years ago in C64 BASIC :laughing:

1 Like
#283

I see what you’re saying, but maybe we just need to better organize the reference guide so that core features are first and easy to read?

I’m also not arguing that things should be more complex than necessary for a given feature/use case. I really like where we’ve ended up with the synthesized list of Turtle ops, to get to this simple version you first have to ideate through the complex versions.

We’ll never figure out the really amazing opportunities if we aren’t willing to have the conversation that delves into complexity, and I don’t think anyone wants to implement things that are needlessly difficult.

I don’t see a system spiralling out of control here, and @tehn has a good handle on how complex is probably ok. Difficulty/learning curve doesn’t necessarily mean it’s too complex. It just might be a feature to learn after mastering the core.

But I also do think that it’s ok for a product to have features that not everyone uses, as long as the core functionality isn’t affected.

As far as I understand bug fixes are happening and this isn’t slowing them down. They are all tracked in Github (https://github.com/monome/teletype/issues) and can be prioritized.

I’d love to hear what you’re thinking around more i2c integration with Ansible, as that’s something that I don’t think has come up much in this thread.

6 Likes
#284

i’d love to be able to return the cv out values from ansible when running kria (meadowphysics, too) so that i may sequence just friends in synth mode.

3 Likes
#285

Yep, and of course it is okay for a product to have features that I do not use…:grinning:

Yes, and I am happy that this conversation now seems to have led to good compromise. I think I get a bit concerned when this process gets too fast with new propositions.

Of course everyone uses devices in a different way and has different needs and ideas what they could do/be. But I have a Reflex Live Loop which I rarely use because it got to complicated through a process of implementing all possible ideas and features.

There seems to be a trend to expect modules to be able to do everything which I don’t think is a good idea. I experience this watching the 3 HP minimal panning mixer thread and have a feeling that the Omnimod disappeared from reality for a similar reason. Even Mac OS seems to have gotten more complicated by implementing stuff that might sound great but isn’t. I just don’t want to experience this again in my rack…

What spontaneously comes to my mind:

CYCLES:

Setting acceleration/friction per cycle
bumping/breaking individual cycles
setting the speed for individual cycles
Setting individual Pulse division

KRIA:
Transposing CV outputs pre/post scale
Reading CV outputs (might make transposing post scale obsolete)
Sart/Stop KRIA

TELETYPE:
Quantizing to scales

1 Like
#286

This would be super, particularly if there was a way to support user-defined scales.

#287

Alright, I have a conceptual problem with BOUNCE mode: where is the fence, and where is “0,0” for each cell. Consider:

@BOUNCE 1
@MOVE 0 -1

Is the turtle Y = 0 or 1? If he was standing at (0.5, 0.5) and the fence were at (0, 0), Y would be 0. If he were standing at (0,0), Y would be 1.

Options:

  • Fence at “edge” of cell, such that len(FY) = FY2 - FY1 + 1
    This means that if you’re at “bottom edge” of (0,0), you need to move 2 whole units to exit the cell if you head up and bounce off the “top” edge.
  • Fence in middle of cell, such that len(FY) = FY2 - FY1