#6

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.

1 Like
#7

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.

#8

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.

1 Like
#9

yea… both sounds good :slight_smile:

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

#10

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?

(Teletype) expanding scripts: length and amount
#11

found some discussion around functions we had before:

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).

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

#12

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.

#13

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

1 Like
#14

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

#15

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

2 Likes
#16

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

1 Like
#17

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? :grinning:

2 Likes
#18

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

#19

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:

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?

3 Likes
#20

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 :stuck_out_tongue_winking_eye: ) 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.

#21

agreed. having DEF #THING could be a good way to do it.

or just inside F,

#DEC
X ADD X 1
BRK

where #DEC gets assigned whatever line number it’s at

and then

F #DEC effectively calls the function

we could then build UI to list # def’s and jump between them.

4 Likes
#22

I run through the exact same thing all the time. What starts as a well defined set of scripts ends in a mess of lots of unrelated commands crammed together in every script.

#23

Expanding on this, consider:

#DEC
Q ADD Q 1
#INC
Q SUB Q 1
#WHAM
TR.P 1
[ … note absence of explicit break or return var commands … ]

… where “Q” is a local variable that is passed as an optional argument and returned to the calling code, like so:

TO.CV 1 V F #DEC TI.PRM 1 // one less than telex param 1
F #WHAM // nothing sent so “Q” is 0 in #WHAM (avoiding null values), return goes to bit bucket

#24

variable args aren’t in the TT engine, so without a hack and a divergence from syntax, we could do this but maybe split it into F for no args and FA or call with args.

but we also need some sort of return specification, or does Q just get returned also?

also keep in mind the idea is that calling F can be multi-line. it should keep running until hitting BRK

#EXTENDEDINIT
A 1
B 2
C 3
BRK

then inside init:
F #EXTENDEDINIT

2 Likes
#25

This makes the implicit return and single local arg/variable problematic–debugging would be unintuitive. I think the named entry points you propose (versus the line number prefix) is a pretty big win.