(Teletype) expanding scripts: length and amount

hey its open source… nothing can stop you from implementing it yourself! getting that merged into the master branch is another story… :wink:


Come on, I know everyone’s passionate about their position but let’s keep the discussion civil.


I believe in referring to the spirit of TT, @saintcloud is describing a similar thing when I refer to the elegance and immediacy. On paper the module sounds kind of boring – who would want to code in their modular? Certainly that was my first reaction. But the design of it makes it such a joy to use. I think that is the point that many of us want to see preserved.

However I’m sure we also see the potential benefits of more lines of code (however that’s implemented) and would be happy to see someone write an alternative firmware. But like @freqout says, bringing that to the main branch is another thing. Cordial constructive discussion would be key.


Have you concretely been blocked by that 6 lines limitation? :no_mouth: Could you post examples? Honestly, i have been writing “complex” scenes for a while and rarely faced that problem (or when i did i just had to find a more efficient code).

It is certain that limitless lines would open up a world of possibilities like fully mirroring existing modules (like the M.U. Marble for example), but we would kind of lost the minimalist spirit of the TT (and monome products in general).

The TT is open source so if you find people interested in taking another path that the original one it’s cool i think, just do it and create a new branch.

And by the way, this forum is a peaceful place full of nice, reflexive and sensitive people (it seems), let’s try to keep it that way please… :confused:


right… and think about how a new user might approach it… they may mistakenly assume that ~more is more~ and go with the 6+ line flavor and miss out entirely on the beauty of the original design.


Teletype, like all instruments in the monome ecosystem, is opinionated. It is flexible and has changed a lot over the years, but part of its excellent design is its boldness. As such, I think that feature requests and related discussion naturally cut to a core in its users that is fundamentally more “charged” than most modules.

The [something] of Teletype is further documentation of the sense of functional mythos it generates in folks.

It is very fun to see how much distance there is between users’ needs. These conversations are wonderful + necessary and if everyone feels respected + heard, certainly actionable.

edit: I will add that grid integration has me longing for another set of 8 scripts, just to manage each-button-does-a-different-thing stuff. As the i2c ecosystem grows, the question of expanding or supplementing Teletype’s role at the heart becomes more necessary to answer.


The zen of teletype (for me) is the readability of the language/script, and that there is nothing “hiding” on the screen, a script is a complete and completely visible creation. I feel like keeping the 6 line limit ensures this.
There are always other scripts that aren’t visible, and I feel nothing special towards the 8 script limit because there’s already more than 8, two others that operate fairly idiosyncratically.

Having a second or third (or xth) series of 8 scripts ( 1A-8A, 1B-8B?) is the initial organizational role that comes to mind for more potential scripts. 8 is a very pleasant number to work in. (You could round-robin scriptssss)

+1 for

This is critical- Teletype is too good at what it does to be this limited!


Blockquote edit: I will add that grid integration has me longing for another set of 8 scripts, just to manage each-button-does-a-different-thing stuff. As the i2c ecosystem grows, the question of expanding or supplementing Teletype’s role at the heart becomes more necessary to answer.

The only problem is that those scripts would not be related to any input. So maybe that a set of only “callable” twin scripts could be interesting and accessible with alt or whatever. It would be easier to read and would not change anything in the actual interface.

And by the way, what about the limit of VARIABLES :sweat_smile:
Just joking
(no in fact i’m not :kissing:)

right! maybe an extra batch only if have additional things? i’d love if the grid ops brought in their own grid-specific scripts, for example.

also, the thread title does remind me i am pulling things off track by speaking of additional scripts vs additional length. :pensive:

1 Like

I have 2 TXo (soon to be 3) and 4 TXi plus a Just Friends connected to my Teletype. I can easily consume the init script and scripts 7 & 8 just getting inputs and outputs set up. A longer init script would be a godsend.

I don’t find the 8 scripts X 6 lines limitation to be too constraining otherwise most of the time.

1 Like

Sarcasms :thinking:? Not playing that game sorry.


I agree with you about the init script, I frequently encounter issues when switching from a scene to another one with differents triggers length or MAP parameters (I use 2 txi) etc…

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


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?


I love this idea. 20 characters

1 Like



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.


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.


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


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)


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.