(Teletype) expanding scripts: length and amount

Monome
#93

per this and other threads where we get some passionate monomers chatting about things they give a shit about and someone tries to rein in the tone. (not calling it a bad gesture, i think it can be important to say) But i think the consistent down side to the callout of something like “let’s chill out” is that it has a way of implying someone or a specific group was crossing a line. While the actual statement is likely supposed to come off like … let’s all cool down a little. Seems like when we hit these points some one always ends up feeling responsible which doesn’t really help anything.

People really like these tools and have weird attachments to certain limitations/features. I think there’s a validity to your idea @knightswhosayneve , imho I think some of the opposition you might be feeling is more people looking out for you as it’s been a topic that’s come up several times and it seems like the powers that control the master branch aren’t thrilled about longer scripts or alt scripts. They obviously have the right to their opinion, and so do you.

Acknowledging that you can build your own branch and do whatever you’d like w/ it, I’d still think there’s a place here to converse w/ others who share your interest about how best to implement.

I can honestly see both sides, I really love the simplicity, but personally no idea for expanding feels foolproof yet (but such is brainstorming), hoping this convo can keep going in some capacity

6 Likes
#94

first some random thoughts.

it’s not as easy as just increasing a couple of constants. i mean this both from development point of view (you would need to implement the whole UI to go with it as well, not a trivial task), but more importantly from the ecosystem point of view. teletype has a big user base. i love the fact that it has both coders and non coders among its users. we have multiple studies, extensive documentation and several threads sharing tips and tricks. any change must be carefully considered.

teletype is still very much a monome product. it represents monome vision. as such, @tehn has the final say on what goes into the official version.

having said that it is entirely possible to create your own version. i would most definitely encourage people to try that and will be more than happy to help get you started. and if you remove the constraint of integrating it into the official version you can implement things in a much more efficient manner and take some shortcuts (and change things to reflect your personal preferences). one thing to consider - teletype is still being actively developed. you will need to be prepared to rebase your work periodically.

having your own version will not only allow you to have the freedom to implement whatever you need (hey, how about some cool new ops!), but perhaps will encourage you to participate in the official development. and having a working prototype is the best way to advocate for your changes (i’ll just say that the initial proposal for grid ops was met with some doubts : )

i would be against having configurable settings. this would discourage code sharing.

this was mentioned already - there are several different ways we can fit more into less. we should explore other options as well (functions / more variables / arrays etc).

and now i’m going to sum up my main criteria when considering new features: elegance. or, expanding it: any new features must fit into the existing design elegantly, and they should make teletype work more elegantly as well.

seeing the whole script on one screen is elegant. however, i agree with several posts (and i expressed this before), there is a point where 8 scripts / 6 lines limitation works against it. i’m an old coder, i appreciate readability much more than efficiency. there is a point where the constraints don’t add anything other than making a scene unreadable. i think we have to be honest that there is nothing elegant in doing certain hacks just so we can fit in more functionality. if we want to encourage re-use of existing scripts we should encourage workflows that make making elegant code easier, not more difficult.

@tehn was pretty clear about his opposition to adding more scripts. i’d like to make a proposal though, and see if this is something that would satisfy the elegance criteria.

8 shadow scripts

SHIFT-FN opens a shadow script for editing
tab switches between live/tracker/scripts/shadow scripts
you can also switch between a regular script and a shadow script by using Pg Up / Pg Down
shadow scripts will not be included when switching between scripts with [ ]

shadow scripts only get executed when called
to execute a shadow script new op is introduced # n edit: SSCRIPT n alias $$ n

why i think this is elegant:

teletype was conceived as an event processor, that’s why scripts are associated with triggers. this concept works well but when you run out of space you are forced to use another script as an extension, which means you lose that trigger (well, not really, lots of fun can be had triggering things that shouldn’t be triggered but my point stands). another case is using loops, right now using a separate script is the only way to fit more than one line in a loop. in both cases we already lost the initial elegance of “each script corresponds to an event”.

shadow scripts can store that logic in a place that is separate yet still easily and intuitively accessible. it keeps the purpose of the trigger scripts pure, they react to triggers. the logic can go to the shadow script, when needed. main navigation is only minorly affected (one more thing tab would have to scroll through). shadow scripts are separated in the interface enough that they are barely noticeable if you don’t use them.

if you want to simply use a shadow script as additional 6 lines, simply add # $ (edit: $$ $) at the end of your script and use Pg Up / Pg Down to switch back and forth.

what say you?

30 Likes
Monome ecosystem firmware development backlog
#96

I love this idea. 20 characters

1 Like
#97

tt

11 Likes
#98

I’m a newer Teletype user, so my opinion may be shaped by that, but I feel that the limitations should stay in place in terms of script sizes. This discussion may end up being like VIM vs Emacs (macros specifically), if you know what I mean.

It seems that there is so much to explore and limitation can lead to more creativity.

4 Likes
#99

Reading around the forum a bit, I prefer the function concept, as discussed in the last few posts in this thread:

One big… definition thingy (not a “script”) in the scene, which can’t be called but contains functions you can name meaningfully and use from live mode or scripts. That way, the whole concept of scripts remains clean –
short bits of stuff that happen when a trigger is received – but there is room for more code while improving readability.

3 Likes
#100

Shadow scripts are cool, especially for looping as noted, but I would still love a 30+ line init playground.

4 Likes
#101

i like the idea of making init script longer and scrollable (i suggested it in that thread linked above but it didn’t get support).

it’s one script that typically takes more than 6 lines for me precisely due to its nature. setting things up can’t be done efficiently. and once done you don’t need to revisit it that often, so the benefit of seeing full script at a glance is diminished.

for the record it’s the only script that i’d want to make longer than 6 lines (okay, maybe metro as well)

9 Likes
#102

Yup, 9 times out of 10, I run out of lines/scripts when I’m calling other scripts from I because I’ve run out of room in I.

#104

Page up and down also helps with maintaining a spatial mental model of script length and position without requiring line numbers. I like that suggestion for scroll behavior.

2 Likes
#105

they would also work well as temp storage. i often find i want to try a variation but don’t want to lose what i already have. having them easily accessible would mean it’s easy to copy lines between the 2.

what would make it especially useful is that they would get stored with the scenes too.

2 Likes
#106

The growth of support for external modules certainly merits consideration of how to relieve pressure on scripting density. Not that I have any real scratch in this game other than being a user, but as they are an active developer for Teletype, I feel like @scanner_darkly’s proposals reflect deep consideration of the way TT already works and why.

I’m all about their suggestions. +1

2 Likes
#107

I really like your vision for the shadow scripts.

My only suggestion would be to fire them off with the same command as launching the other scripts to keep it simple. The shadow scripts could be numbered 9 through 16 or by putting a 1 in front of each one, i.e. 11, 12, etc…

Now, would this be the wrong place to talk about more patterns? :slight_smile:

#108

i would be afraid to hide them too much (they need to be fairly easily discoverable but not get in the way).

they should not be included however when scrolling through scripts with [ and ], i added that to my post.

2 Likes
#109

this would lose the association between regular scripts and corresponding shadow scripts. i think it’s more intuitive when you think in 8s - 8 trigger inputs, 8 scripts, 8 shadow scripts

2 Likes
#110

this would lose the association between regular scripts and corresponding shadow scripts. i think it’s more intuitive when you think in 8s - 8 trigger inputs, 8 scripts, 8 shadow scripts

Fair point on the 8s. Is there a reason you went with # as the operator as opposed to something with S or $ in it?

#111

But we’d need some way of differentiating between a shadow script call and a normal script call in the grid ops. Unless we default them to shadow scripts? Which would make sense I guess.

1 Like
#112

As far as I know it’s one of the only single character op names that are still available (which is a thing worth pondering over too).

#113

no particular reason, just seemed like an intuitive choice. it might have to be something else though as # is a special character (it’s used to separate scripts in saved scenes). both S and $ are used already.

edit: SSCRIPT and alias $$ could be a good option. which would make calling a shadow script from its corresponding trigger script look like $$ $ :slight_smile:

i thought for grid ops negative number can indicate a shadow script.

2 Likes
#114

$$ is great: it’s descriptive (shadow script), short, and doesn’t use up our precious #.

That feels a bit weird to me. I don’t have a grid myself and haven’t played around with the grid ops yet, but I imagine that the vast majority of the scripts called by grid interactions are only meant to be called through grid interactions and not trigger inputs; a shadow script would be the default case. In a case where you’d want to trigger it through the inputs, you could simply call that shadow script from a regular script. This would also allow differentiating the source of the script call, allowing different routines to be run accordingly. Of course you’d still be able to do this with what you proposed. My proposition also has the drawback of potentially wasting a script in a non-default case. This is really just siding with simplicity of parameters.