Argument Expansion -> Functions

[sliderule]

In the TT Short Aliases thread, SCALE was a popular request for shortening. I think something that may help would be to permit users to store groups of arguments for later use. Consider:

#I
AG 1 0 V 10 N * X 24 N * X 48
AG 2 0 V 10 N * X 60 N * X 12

#M
EVERY 3: CV 1 SCALE &AG 1 IN
OTHER: CV 1 SCALE &AG 2 IN

#1
X + FLIP 1

---

Notes

• AG means Argument Group
• Its first argument is the AG index
• All remaining arguments are stored in the AG
  • Fits as many commands as you can stuff
    • _{yes, this is a departure in syntax and the parser would change}
• &AG evaluates and expands the arguments into the current command

This solves all sorts of using-long-commands-with-MODs problems, IMO, but I’ll admit that it’s radical.

Name

I guess it could be called OG for Operator Group?

[jamescigler]

Although I was one of the folks who thought shortening SCALE would be nice (or having more utility map tables like V, VV and N), this can get really complicated to abstract - for me anyway.
I’m also thinking of when you go back to a SCENE after a couple weeks and have to figure out what it does.

In an older thread, I remember @tehn mentioning the idea of more SCRIPTS. Let’s say 9-16. They wouldn’t be triggered by the 1-8 trig ins, but simply there to be called from the main 1-8 scripts. Initially I thought “bah, 8 is plenty and a nice creative limitation”, but, there’s definitely cases where you have to call another SCRIPT if you want to do some kind if PRE: PRE operation.

It would also work in this example.

#M 
EVERY 3: SCRIPT 9

#9
CV 1 SCALE 0 V 10 N 24 48 IN

And if SCRIPT had an alias of $, you could even SUB multiple SCRIPT calls

EVERY 3: $ 9; $ 10

All this to say though, as a new user on the platform, it’s waaaay easier for me to follow along that one script calls another script and I can clearly follow how things get executed in each one, and what values are used.

[sliderule]

Yes, script calling is one workaround. I should have mentioned it it the top post. It would be a shame if that was the only solution, though.

[cmcavoy]

In an older thread, I remember @tehn mentioning the idea of more SCRIPTS.

I don’t know the original thread but this would be fantastic. I use scripts like functions.

[jnoble]

I would use them more like functions if I had more available.

But it would really come in handy for long init scripts–I have two TXi and two TXo, and I have been eating up one or two scripts plus the init script and/or typing stuff in from notes. Really complex setups could take even more.

[scanner_darkly]

it feels a bit specialized. @ether suggested before introducing functions, which to me feels like a simpler / more readable concept (very similar to what you suggest).

define a function: F id: ...
execute a function: F 1
each function gets a special variable RT (for “return”) which can be used for the function to return something.
each function has access to N special variables PR (for “parameter”) that can be used to pass parameters in.

example:

F 1: * / PR 1 X + B C
CV F 1 1

edit: don’t actually need RT
edit2: my memory failed me, the idea to introduce functions belongs to @ether

and i’d love to have 8 more scripts that would not be attached to triggers. this would make things more readable by hiding logic in these additional scripts therefore making the intent of triggers scripts clearer.

[freqout]

I like the idea of functions and the idea of extra scripts, but what if they were combined? Scripts 9-16 could be functions… scripts that can accept multiple locally scoped arguments. You could pass however many parameters after the script number and read them inside that script via PR.

[scanner_darkly]

or both. we could make SCRIPT support parameters as well, so you could either use a whole script as a function, or define a bunch of smaller functions.

[freqout]

yea… both sounds good

are the functions you are proposing available globally in all scripts or only within the scope of the script they are defined in?

[sliderule]

or both. we could make SCRIPT support parameters as well, so you could either use a whole script as a function, or define a bunch of smaller functions.

Scripts 1-8 would essentially be invalid when triggered if they relied on the parameters, right? If so, it kind of begs for a different operator, no?

[scanner_darkly]

found some discussion around functions we had before:

(Teletype) Pre-2.1 Operators and Features

Some random thoughts here. We have LIVE, EDIT and TRACKER modes already (I’ll ignore SCENE modes for simplicity). How about a SCRIPT (or EXTENSION) mode, which is really just one long, scrollable page (up to the limits of the module) that can be used to write callable functions? e.g. (Imagine something like this all on one mode/page) FUNCTION MYRANDOM RETURN RRAND 1 12 END FUNCTION FUNCTION WHATEVER DO SOMETHING INTERESTING END FUNCTION etc. I can then call MYRANDOM and WHATEVER from…

i corrected my earlier post - the idea to introduce functions belongs to @ether, apologies for claiming it earlier.

from that thread i like the idea of having a separate screen for functions which will have more than 6 lines, and the idea of distinguishing functions with a special character (and being able to define aliases - this would really be great for readability).

Scripts 1-8 would essentially be invalid when triggered if they relied on the parameters

in this case parameters could default to 0. you probably wouldn’t use triggers for such scripts anyway (although it’s great fun to circuitbend some carefully assembled scene this way!)

[scanner_darkly]

are the functions you are proposing available globally in all scripts or only within the scope of the script they are defined in?

globally, that would be much more useful. would be even better to be able to define functions outside of scenes (so they could be used in any scene) but this would make storage and scene exchange much more complicated.

[sliderule]

I will note that @tehn believes that the Timeline feature will solve similar problems, and hence overlap the the idea of functions.

[scanner_darkly]

there are some differences though… but i think the 2 could be combined elegantly.

[tehn]

reasserting my preference for timeline (which we renamed F, right?)

we can think of ways to integrate args, or just conceive of a few more variables

[chapelierfou]

I do not grasp all what’s being discussed here, but i’d love more scripts !

[jnoble]

reasserting my preference for timeline (which we renamed F, right?)

we can think of ways to integrate args, or just conceive of a few more variables

The downsides I see to the timeline are scrolling (which is a small issue to some) and the minimum loss of 2 characters’ width for timeline commands. The latter seems more important to me.

I love the idea of adding scripts 9-16, though it might help to take them out of the [ ] “1-8, M, I” cycle with a shift/script mode key. I frequently need 3 or more scripts (including “I”) just for initializing scenes (two TXi and two TXo here … and JF will be joining the party soon), and the setup commands tend to be on the long side because of the TX./TX. prefixes I use so much.

Can we do both?

[bushel]

+1 for more scripts! Having several available to call but not necessarily trigger would be incredible.

[scanner_darkly]

what i really like about functions is aliases. with more complex scenes it always takes a while to figure out when you come back to them later, and using scripts as functions usually makes it more difficult, not less. the reason being - i usually start with each script having a well defined purpose but as the scene grows more complex and i run out of space i have to re-use scripts for different purposes and this doesn’t work anymore.

having well defined functions would improve readability significantly… and i really like what you suggested for having a special character for aliases:

(Teletype) Pre-2.1 Operators and Features

aliases are something i’ve considered. it’d need a special character.

ie

DEF #DEC X SUB X 1

and then #DEC could be used anywhere instead of X SUB X 1

so combining this with the timeline could work this way - commands in the timeline could have either timestamps or function aliases, so essentially it’s just 2 different ways to execute a timeline script.

having parameters is less important as variables could be used for that, but yeah, it would be great to have more variables then so you could dedicate some of them purely for function calls. especially if we could have an array variable (so, sorta like a pattern bank but just a single bank).

agreed it would be great to expand INIT somehow. if we do a scrollable timeline, perhaps INIT could also be scrollable?

[jnoble]

A scrollable init script would be a good solution also.

I’d be more in favor of the timeline concept if it was block-oriented like so:

BLOCK FOO:
TR.P 1
X + X 1
BLOCK BAR:
TR.P 2
Y + Y 2
BLOCK BAZ:
TR.P 3
z + z 3

etc … which preserves the full width of the lines and lets us name (rather than number) the groups.

I’m not thrilled about scrolling, honestly, I really appreciate not having hidden stuff right now–it’s less confusing when modifying scripts in a live setting, and I don’t want to have to either guess/remember whether I need to scroll to see the rest of the script or squint through my old man glasses (progressive lenses aka bifocals for people in denial ) at an indicator icon to see if there’s something I’m missing.

The init script is a special case, of course, and I think scrolling might be an OK compromise since it’s not really that fun to hunt through a chain of other scripts to see if I am setting up that $#@$% TXo envelope twice etc.