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

#70

no, this is the right thread. what i meant was - instead of adding 2 to existing ops it would need to use something similar to pattern ops, where the bank can be specified as a parameter. so then there would be separate turtle ops that would take the turtle number as a parameter.

1 Like
#71

Ok after some years of using these are the little things that i miss every time:

  1. More variables (even 2 or 3, but the whole alphabet could be nice).
  2. A simple way to do stuff like “IF … then PROB … to do …”. This kind of stuff would take 2 pages at the moment.
  3. I always liked the TIMELINE idea or at least the possibility to globally stock blocks (or lines) of code and easily recalling them (in a script way like $1). Maybe with another available symbol?
  4. Longer INIT script.
5 Likes
Monome ecosystem firmware development backlog
#72

Could we have a way of calling the metronome and init scripts programmatically with variants of the SCRIPT or $ commands? Would be handy to be able to trigger extra metronome pulses and/or initialise a scene on trigger input. $ I makes sense but wouldn’t work because I is a variable, so maybe just $M and $I? (At this point I’m braced for someone telling me this is already possible of course - in which case, thank you!)

#73

yep, M and I are 9 and 10 respectively

2 Likes
#74

right now SCRIPT op will only execute if the script number is between 1 and 8. agreed we should extend it so that you can also use 9 and 10 for metro and init.

2 Likes
#75

yea didn’t know you couldn’t use them w the SCRIPT command, just assumed you could because that’d be more consistent w being able to manually trigger them w F9 and F10.

#76

cool, so if we’re agreed I’ll go with DEL.X and DEL.R. possibly could be changed before release if someone comes up with something better. I’ll get a pull request out tonight.

#77

pull request

bonus DEL.X sound clip
https://soundcloud.com/alphacactus-111884871/delx

4 Likes
#78

will take a look tomorrow!

1 Like
#79

Just a thought. Wondering if the addition of 2 local variables might make a big difference in preserving globals for a more global purpose.

A pretty common construct for me, due to max line length:

Global1 [expr]
Global2 [expr]
IF [conditional] Global1 Global2: [expr]

Right now I think the only local is “I”, which may already be set and in use if the script is invoked from the loop op of another script.

5 Likes
#80

additional temporary/local variables is something I’d really like. from what I know this seems okay. I could start looking into implementing this if there aren’t any concerns.

3 Likes
#81

what should they be named, maybe I1 and I2?

we could follow the existing pattern and use a single letter but maybe we should keep single letters for some future global vars and ops.

since some features are already being implemented i’m going to post beta versions in the OP as things get added. posted a beta that includes the fix for vortex keyboards and new DEVICE.FLIP, DEL.X and DEL.Y ops.

3 Likes