#127

I agree, I wouldn’t want new features at the cost of stability.

Would anyone developing like some help testing new builds? I worked QA for several years. I’m not sure I’ll have time to do full regression on a build but I can definitely help test new features and perform stress tests.

2 Likes
#128

i like timeline as a feature. i don’t think it’s an elegant solution to script length. you are solving the problem by introducing one big scrollable script - the very thing you argue against for existing scripts.

also consider the navigational aspect of it. you trigger a script, something doesn’t work. the logic is in the timeline, so now you have to jump to timeline (another keypress? is it included in tab scroll?) and then you need to find the relevant bit, the only navigation you have is scrolling. shadow scripts put relevant logic within immediate reach.

shadow scripts would most definitely need to be distinguished visually. users should have an immediate idea of where they are simply by glancing at the screen.

3 Likes
#130

Yes, indeed, so the $$ pages should look different than the regular ones.
So, why not inverting the colours of the shadow page: yellow screen and black text?

1 Like
#131

come on, we sinners with hopes of less concision have eyes, too.

(edit: i was actually replying to the above black on yellow proposition.)

1 Like
#132

My initial thought too. Difference might be a bit too drastic though

#133

A different way to consider shadow scripts… what if they weren’t “scripts” at all, but a New Thing™: “Functions”
Functions can have one (optional) reserved variable that gets passed in from the caller, and is unique to that particular function. It could also (optionally) return a value. We can have 8 functions, and they have each still have a 6 line limit.

What think?

3 Likes
#134

I think it’d probably be most elegant to call them 11-18 and display that in the bottom left corner. I wouldn’t prefix (something like S1), because if you did that, then you can’t use numbers to remotely call the shadow script (Teletype doesn’t have a way to concat a letter and number into a “string”, at least that I know of).

I think it’s mentally simpler to continue to use the SCRIPT op to execute these, rather than introducing a new operator like SSCRIPT.

Number 11-18 and utilizing the SCRIPT operator allows you to do cool things like

SCRIPT ADD A B, where A could be 1-8, and B could be a toggle of 0 and 10, allowing easy A/B’ing of the Script and its requisite Shadow Script

From a usability perspective, A teletype user knows to look at the bottom left corner to see where they are.
This would be sufficient, and in my opinion, less aggressive and distracting than say, inverting the colors. In my experience, the best UX decisions tend towards consistency rather than new concepts.

1 Like
#135

I too throw my vote in with @scanner_darkly regarding shadow scripts. FWIW, there is no “forced” anything in Teletype firmware, @tehn has final authority on what gets folded into master and from what I’ve seen and participated with in some small way is vetted by the community for functionality and usability well before it ever becomes an official firmware release.

1 Like
#136

So what would be the advantages compared with scripts shadow scripts ?

#137

it feels like the topic has grown beyond “Teletype max script length”. anyone disagree with changing the name of the thread to match convention and content? “(Teletype) expanding scripts: length and amount” seems right, but open to suggestions.

5 Likes
#138

9 and 10 are currently reserved for metro and init (not callable via SCRIPT although i don’t see why they shouldn’t be, but attachable to grid controls).

i’d like to emphasize the usability aspect of anything we consider. half of my proposal is about navigation. it’s only fair to compare different workflows if we also have a good idea about how they would work in practice. so here’s my challenge: how would timeline or functions fit into the teletype UI?

i should’ve started a separate thread for this, apologies. perhaps mods can split it into one.

1 Like
#140

I can start sketching some visual ideas any time!
:grin::+1:

1 Like
#141

Thanks for the clarification, I’ve updated my comment to reflect the shadow script values being 11-18, as being +10 from the actual script is actually not really anymore inelegant, IMO

#142

I guess it retains the notion that scripts are tied to the trigger inputs, and it also addresses some other issues people have mentioned about lack of variables. I often waste variables as parameters and returns, setting in one script before calling a subsequent script, for instance

#143

adjusted. happy to revert or split if it feels necessary to the community.

4 Likes
#145

I don’t think I like shadow scripts because of the amount of visual and language differentiation that will have to happen for exactly/only 1 “alternative” state per script.

heres a doodle i thought of this morning.

FullSizeRender

-no new naming conventions, just a . between script and layer, layer 0 default
-Set a flag per script on whether or not to follow to the next layer
-fly direct to layers with an indication like $ 1.2
-navigate through with pg up/down
-script layer easy to indicate in the display corner

i really wish i had any sort of programming chops to roll something like this myself and actually make it. perhaps that would be a good life goal.

2 Likes
#146

Very nice! I’d recommend getting rid of the . @bushel, so the scripts are addressable with integers, which are easily mathematically composed from operations you can do (I talked about this a little here)

This seems like a pretty elegant solution to the problem, I think.

EDIT: you could also have layers at the metro script which is addressable at “9”. So like 9, 19, 29, etc.

#147

i find this statement sadly ironic given that it appears in this thread. it also makes me think of all the features that were added by teletype contributors as complete visions, without community input.

i’m taking the “forced decisions” comment close to heart. much to think about.

3 Likes
#148

apologies, i’m late to the game.

i acknowledge that the scope of possibilities in the TT environment (due to massive i2c expansion and @scanner_darkly’s grid-ops) has created the need/desire for more script space.

i’m still fundamentally in favor of the “timeline” proposal (which had some nuanced changes in further conversation of the years)— not just for adding more lines, but because it introduces a new way and mindset of interacting with TT. yes, it’s a scratch-pad, but it’s also a sort of hyper-linked dynamic GOTO machine that could be treated algorithmically for some sort of generative/emergent processes. it’s a different way of interacting. and yes, of course you could just use it to just make a longer INIT etc.

at issue is development time. numerous people have put a ton of time into this codebase and made it better than i could’ve imagined. TT now is not broken. it’s not imperative that it changes. but it should evolve to keep up with demands that are being put on the ecosystem (again, lots of i2c connections.)

i’ll find time to re-propose timeline, with example syntax and interface.

20 Likes
#149

@scanner_darkly I very much value the time you, @tehn, @sliderule, @sam, and anyone else who I am forgetting put into Teletype development. Not only is the module open source, but I feel like it follows an open development model that is done in a way which supports gathering feedback not just gated to people who are savvy at coding, focuses on the user experience (many open source projects treat this as a secondary concern, if at all), and represents an art + tech interdisciplinary vibe that is uniquely lines.

I’ve personally learned a lot technically from reading about the changes y’all have made.

Also, sort of related, I found out the other day that EVERY was implemented as a random side thing one day by @sliderule, and it is something I use “every” (pun intended) time I sit down with teletype :slight_smile:

9 Likes