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
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?