If there were a total of 60 lines of script per scene but I could apportion them between scripts how I wanted, I’d be pretty happy.
2 Likes
I’ve had a lot of fun with Grid and Teletype. I wrote a scene here! However, I felt like working around the width/height limitations tended to obscure rather than illuminate the program structure.
i do think though that the limitations often force you to make things less readable.
I tend to agree. I needed my notes and to “mentally execute” the script when debugging/refactoring. Also, I kind of coded myself into a corner extending scripts with other scripts. The 3 main features of my scene span ~2 scripts each. As mentioned before, you give up a gate input for each script, which unfortunately meant I couldn’t fit in features like pause/play, reset, reverse, etc.
Some of the upcoming/released bit operations may help shorten up the code a little bit.
1 Like
Isn’t that what the tracker patterns essentially are?
that said, I always wish for more variables!
1 Like
Yes it’s true that tracker patterns are just that, but they are fixed. But imagine if a pattern was just a variable. In fact, the PN.[method] notation is just that. Instead of passing the pattern number, it would be cool if I could say, P1.LENGTH = P2.LENGTH or P3 = P5 to assign patterns. And maybe in Live mode, I could say P5.TRACK 2 and it would show up in the tracker, in lane #2, ready for turtle interactions.
I feel the same about the number of variables. The more I progress in coding my TT the more I find myself blocked by that limitation. This is especially true when you start adding some Txi, Txo, a JF etc
… Unlocking variables from letter a to letter z would be a real game changer I think 
Now about the script limitation, I think that is an essential element making TT what it is. I like the puzzle-like coding that force you to be really efficient.
1 Like
after reading all pro and contra concerning the script limitation, wouldn’t it be just interesting to give people the chance of coding more then 6 lines and see what intersting stuff comes out of it?
those who want to limit themselves to the original 6 could stay working as they did before…
2 Likes
Could you be more precise about what you what to achieve (point by point), I would like to give it a shot 
So in short you want:
- Generating scales (randomly?)
- Generate random pattern with the created scale
?
When I first got Teletype I often found myself wishing for longer script length and more variables, but as I’ve gained experience I’ve found that thoughtful coding means this is less necessary. And I really agree with the comment that returning to longer scripts would be confusing.
Remember all positions in the pattern tracker can behave as variables
You can get away with using the same variable locally in multiple scripts without issue, if executing immediately.
Limitations breed creativity
6 Likes
I agree! Tracker patterns really are fine with me, regarding the “array-like” functionality. But, even just following your logic, I would like to have more variable options, just so that I can assign them to all sort’s values throughout the system. With all the i2c options out there, the usefulness of more variables presents itself to me more often now than ever before.
I understand that there are many other letters or letter combinations already in use throughout the syntax, so just using all the letters of the alphabet would not be possible. I think I would appreciate the options that would use a two character variable naming convention, like VA, VB, VC, … VZ.
5 Likes
sometimes that’s right, but if I have to think about an hour on how to put everything into 6 lines and 8 scripts, it also means spending less time making patches&music…
maybe coding limits are great for people who want to test their programming skills, but that’s not essential to me, this nice little eurorack computer should simply be helping me getting more patch for less cable 
but that is just my humble opinion of course…
1 Like
what is it that you’re trying to make that you’ll need more than 8 scripts for?
there has been talk of a Timeline feature before that might fill the gap:
But we’re at 2.3 now and I don’t think anyone has begun developing this feature.
I would move past the idea of keeping distinct functionality in single scripts. If you look at a lot of other people’s teletype scenes, you’ll see that calling scripts from other scripts is a very ~teletype~ way of working. Especially from the equivalent of a for loop (the L pre).
4 Likes
@laborcamp @pascalm Completely understand where you’re both coming from. I guess a module like Teletype we are all going to use in quite different ways. For me it just still blows my mind how powerful it is it’s original state, let alone with all the recent updates.
So much power from calling scripts with the L pre!
2 Likes
I’ve expanded my TT with ER-301 (100 outs), TXI (8 ins), Ansible (8/4) and plan on getting 2 TXO (8 out each), 1 more TXI (8 in), Grid and Matrixarchate (128).
With the TT being the brain for so many inputs and outputs, 8 scripts of 6 lines of code each means 280 I/O handled with 48 lines of code = 5,8 I/O per line of code… Or inversely, 0,171428571428571 lines per IO…
This is not counting Grid w. Grid ops because that is theoretically infinite IO due to multi-page views and what have you…
Compare this to an un-expanded TT you have 0,16 IO per line of code, or inversely, 6 lines of code per IO
It’s hardly sufficient… Sure, with the base configuration I can see how 8 trigger inputs, each corresponding to a script, makes sense… For beginners… But with a fully maxed out TT and Grid w. grid ops it simply doesn’t make sense to impose an arbitrary limit on the user.
I would like to see 8 more scripts, adressed as A-H, with at least 32 lines per script… If you don’t go beyond the screen, then you don’t have to use those lines of code. Also, with these 6 lines of code, you end up having to write more confusing code and not leave comments, in order to squeeze in as much as possible into each script. It’s like comparing business code to tweetcart code. You will end up writing less readable code the less space you have to write it.
2 Likes
Interesting idea to hide away the extra-long scripts for those who need it. I think this could retain the initial simplicity for new users but open up new possibilities for those with lots of iC2 connections.
A-H wouldn’t work though, as A-D would end up overloaded so that calling ‘SCRIPT A’ could mean calling the script A, or the value of variable A
So what about script 1-64 
2 Likes
Haha yea that’s the most logical conclusion. I do like that as well, because it’s obvious that the scripts beyond 8 don’t correspond to any of the inputs on the front panel. So the simplicity is retained on the triggered scripts, but allows them to call other scripts for additional help. Especially useful for I and M
1 Like
i agree that with grid ops, those limits are somewhat frustrating.
Let’s say i have a group of 128 buttons, and i want to test some buttons to act differently, the mono line IFs combined with the 8 script limit make it difficult:
IF EQ G.BTNI 126: leaves 13 characters to do something meaningful.
That makes me dream of writing IF EQ G.BTNI 250: SCRIPT 54 or TL.BLOCK 27 or something like that
(as you might guess i’m currently debugging/optimizing a relatively simple grid interface + semi generative scene and can hear the clock ticking and the pile of stuff that remains to be done in the next 6 hours )
1 Like
It would be wonderful to see an “expanded” mode mentioned above. If not longer scripts then more that the expanders can access. With the ecosystem growing, setting the groundwork for addressing the plethora of inputs and outputs is wise.
I would vote for more scripts rather than longer scripts.
Calling scripts from other scripts , especially with the $ costs so little in terms of space in code that it would make sense to keep the 6 line limit.
Even the previously discussed ALT set of another 8 scripts would be a huge difference!
6 Likes
I too would rather have more scripts than longer scripts. The “readable at a glance” quality is nice imo.
3 Likes