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

4 Likes

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

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.

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

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

@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

we all know this isn’t true :slight_smile: your efforts are deeply appreciated.

TT has had an incredible evolution— solidly grounded in input from this community since its release. i view it as a collaboration between a handful of dedicated designers taking into account the requests of everyone using it.

but this happens often— when a need is present, all sorts of proposals are made which makes things feel like they lack a cohesive overall vision. this is normal for development out in the open.

10 Likes

May I suggest a page-able init script instead? Then the bottom left could read “I-1, I-2”, etc. and we would still have the “I can see all the code on this page” standard.

I really would love to hear see what you have in mind regarding the implementation of this.
I have some immediate interface thoughts that are prompted by this concept, but am very curious how you see it in your head!

4 Likes

I too am very curious. a timeline of any sort sounds like a powerful tool/concept.
it does seem like a lot to add a whole new facet of interaction/syntax/interface to respond to the fundamental “there isnt enough” problem here though.

Exactly: we all want this.
(Regardless of whether one thinks of it as an “elephant” or not.)
:wink:

2 Likes

I often have this thought about Teletype when I’m using gibber or tidal. The pattern language is just such a great way of thinking about time and rhythm…

But I’m not saying no to the timeline idea (because I honestly don’t believe I grok it yet).

1 Like

@scanner_darkly to be honest i do like your shadowscript idea-- my hesitation is really only that it overlaps with something that timeline would readily fulfill-- and so the eventuality that timeline is implemented it’d be a drag to feel compelled to take away an existing feature (yes, i would feel compelled, because minimalism).

but. all reality is that i can’t put the time into TL. so it’ll just stay a pipe dream feature until i get the time.

hence, i think you should go forward with the shadowscript if you’re feeling it.

8 Likes

i recommend everyone revisit this thread from september: (Teletype) Pre-2.1 Operators and Features

script arg proposition by @scanner_darkly and lots of discussion about TL

livecoding UI proposition: keystroke for execute current line, and execute block (all lines with same line number)

9 Likes

to clarify: i am totally fine with criticisms of ideas. i engaged in the discussion of the proposal itself. but at some point that discussion gained emotional aspect, and i have no desire to participate in that aspect. perhaps the fact that i’m reacting to it strongly is just another indication of how passionate we all are about teletype. but that’s yet another reason why it wouldn’t be healthy for me to participate in this discussion further.

my comment was also in regards to another elephant in the room - the development process. there is only a handful of people actively working on the codebase. i think i can speak for all of us in saying that we do it because we enjoy doing it. but that is fueled by passion to implement certain features, and it’s no secret that the developers have more say in what goes in (assuming @tehn is okay with it). it’s a 2 sided coin, on one hand you have somebody who put a lot of thought into a concept, who was likely able to test it and see how it behaves in practice, and who has a good understanding on how it fits overall. on the other hand, i can see how this would be seen as forcing one’s vision onto something that is a community driven project.

this is an interesting topic in itself but the reason i mention it - i think it’s healthier for the discussion if i detach myself from the shadow scripts idea. the idea still stands, i think it’s articulated enough that it can be discussed, but i think it’s better for the discussion if the source of ideas is not taken into account. with that, i’m going to bow out from this thread and get back to working on 2.3.

16 Likes

(Those of us who might want to talk about timelines again: here, or someplace else?)

(And let me add to the chorus: all work on TT is loved and wanted, and those of us who don’t write C are in your debt. Thank you!)

2 Likes

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

+10 and :heart: s to everyone involved in the discussion, development, and passion for Teletype. You all are a large part of what makes this my favorite module in my system.

So speaking of, it seems like shadow scripts have gained a lot of traction, but there’s a couple questions about:

  1. How do you access shadow scripts?
  2. What kind of affordance does the UI offer to indicate you’re editing a shadow script and not a regular script?

Are there other major concerns we need to rectify?

On point 1. I’m not a huge fan of adding these to the tab menu. I think it may add an extra burden for new users, or when editing smaller scenes to tab through an extra section every time I cycle through these, so I prefer the page-up/down suggestion.

For point 2. a mildly crazy thought I had was to invert the screen, so we’d have black text on a yellow background. That’s probably taking it a bit too far, but I think we should be thinking along those lines – somethings that’s immediately obvious at a glance, so that you’re not stuck debugging why your triggers aren’t firing script 1, when in fact you were editing the shadow script. Perhaps just the top bar could be inverted?

3 Likes

Maybe we could just invert the input line? I feel like it would be too much to invert everything, and the top line may seem strange because part of the script ends up there.

Edit: Also, I like the page up/page down navigation idea. Page down gets you into the shadow scripts, and then the [ ] keys cycle through them. Page up to get back to reg scripts.

7 Likes

I’m a genuine fan of both the timeline and the sscripts, and have loved being here reading this passionate discussion. I lean towards the sscripts being more intuitive for me personally as I imagine page down, inverted bottom bar as mentioned by @Justmat and then can move [ ] to other sscripts.

Something mentioned a few times is the topic of freely assignable sscripts, but hasn’t been directly addressed (unless I’m mistaken). I personally would prefer freely assignable scripts rather than associated scripts, but would be open to hearing others thoughts on this.

Last thought, I imagine by paging down into the sscript layer and moving [ ] and then paging back up, i’d imagine being in the same spot i paged down in, rather than paging up in an “associated” script. Seems a good way to not make it feel like I’m supposed to associate trigger scripts with sscripts.

Love reading all your ideas, thanks everyone!

2 Likes