#50

not sure about XDEL.R naming, dot notation is mostly used for 2 main reasons:

  • some setting related to the original op: DRUNK.MIN, TR.TIME
  • a way to group related ops: P.NEXT, P.I, INIT.CV, INIT.DATA

i would go with something like XDELR or RDEL

(i’ll answer dev related question in the dev thread - let’s keep this one for feature discussion)

#51

XDEL.R could be thought of as related to XDEL, imo. RDEL is perhaps much less clear as to how it differs, just from the name, but does save two characters.

#52

but it’s not a setting, it’s an action, so doesn’t fall under the 1st category.

if it was something like XDEL.R setting which could be used to enable/disable ratcheting for XDEL (or get the current setting) it would follow the 1st category, but i don’t think there is a benefit of controlling this behaviour generally.

#53

Right, I was thinking of it as falling squarely into the second category.

#54

then i’d go with something like DEL.X and DEL.R

1 Like
#55

More of a Teletype + Ansible request. Could we have an ansible mode which works as a simple extender of teletype so that grid ops would be passed of the i2c bus and appear on a grid connected to ansible, and the ins/outs of ansible would be extra ins/outs on teletype? Wouldn’t it be lovely to be able to use both grid and computer keyboard with teletype at the same time?

3 Likes
Monome ecosystem firmware development backlog
#56

not sure this would be feasible (should just test this at some point…), would probably require improving i2c implementation, not a trivial task…

#57

Was there talk previously of OPs which load / save scenes, or did I dream that?

#58

SCENE x to load a scene, no op for saving scenes.

1 Like
#59

Ah thanks. Do you recall why SCENE x doesn’t run the target scene’s I script?
I’m also curious whether SCENE x reinitializes the default variable values (I’m away from my modular right now but I’ll check when I get home).

I’m trying to figure out how classy TT can get at being a finite state machine sequencer. I’ve made some simple “sequence maps” by having the turtle walk a table of state indices, but there’s not much room for radically different behavior between states. If each scene can be used as a state then all that’s missing is “upon state exit” and “upon state entrance” code. The I script seems perfect for “upon state entrance” but it’s not used with SCENE x for some reason…

1 Like
#60

probably so that if you have a meta scene that switches between different scenes it would work continuously. imagine having a group of scenes that all do some transformations on pattern data. if you, say, initialize pattern data in the init script then this would happen each time you switch a scene with the op - probably not the effect you want.

i suppose it could be an additional parameter (would require a separate op though as SCENE can be also used to get the current scene number).

#61

do we think the op is close enough to the original DEL for this to be okay? I thought you had expressed being against DEL.X unless I misunderstood.

#62

i’m advocating consistency - XDEL and XDEL.R combo is inconsistent but DEL.X and DEL.R combo is not. don’t really have a preference between XDEL and DEL.X otherwise (other than DEL.X taking 1 more char…)

3 Likes
#63

It feels greedy to suggest additions to what is already a beautifully poised language whose simplicity is its greatest strength. But…

I’d love to be able to pass an argument to a script. I’m imagining a version of SCRIPT with a second argument, and an extra local variable that would be set to that argument in the receiving script. So, e.g. SCRIPT 2 4 would run script 2 with the “argument” variable local to script 2 set to 4. This would allow for some nice recursive algorithms that I’m not sure would be very easy to do otherwise.

#64

I know it’s not as nice, but is there a reason one of the global variables wouldn’t suffice for this?

1 Like
#65

even better, use I - it’s local to each script (so you don’t really lose a variable), but it gets passed into a called script from the caller script.

7 Likes
#66

Brilliant! That reveals my embarrassing teletype naïveté as a new user… I didn’t know I was initialised from the calling script. That allows for “proper” recursive algorithms (in a way glabal variables would not). Thanks! :slight_smile:

#67

i’ve been exploring turtle a lot lately and have been wondering if it would be possible to add additional separate turtle scripts. maybe it would be possible by adding the turtle operator number at the end of each function? so:

@F2 x1 y1 x2 y2
@MOVE2 x y 
@SHOW2 1

i’m still relatively new to TT, so if this is already possible and i didn’t know about it i apologize!

Monome ecosystem firmware development backlog
#68

it’s a recent change (was only added in 3.0). this allows to simplify doing something like this:
L 1 4: SCRIPT 5 where you need to use the current iteration number in the called script, before you had to use a global variable to pass it in: L 1 4: A I; SCRIPT 5.

not sure it’ll work for recursive purpose though, if you call a script from itself it won’t restore the previous I value once it returns.

this would require a separate set of ops, similar to pattern ops, where the turtle number would be one of the parameters.

#69

sorry, maybe i misunderstood the purpose of the thread - i thought this was a place to request possible future features. this is the first time i’ve had something to request - let me know if there’s a better place for me to file it!