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.
EVERY 3: SCRIPT 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.
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.
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.
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.
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.
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!)
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.
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.
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?
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:
X + X 1
Y + Y 2
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.