#27

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
#29

Could you be more precise about what you what to achieve (point by point), I would like to give it a shot :slightly_smiling_face:

So in short you want:

  1. Generating scales (randomly?)
  2. Generate random pattern with the created scale

?

#30

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
#31

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
#32

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 :slight_smile:
but that is just my humble opinion of course…

1 Like
#33

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
#34

@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
#35

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
#36

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

#37

So what about script 1-64 :smiley:

2 Likes
#38

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
#39

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 :slight_smile:
(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 :smiley: )

1 Like
#40

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.

#41

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
#42

I too would rather have more scripts than longer scripts. The “readable at a glance” quality is nice imo.

3 Likes
#43

Too many more scripts could make selecting them in the interface awkward, so there needs to be some balance. Though I suppose TAB could rotate between live mode, the tracker, a main script page and a “more scripts” page.

4 Likes
#44

please don’t make it too complicated…
why not just allow for longer scripts, those who need “readable at a glance” can limit their program to the first six lines…:slight_smile:

1 Like
#46

I’d love to +1 an extended set of scripts. That would be so useful.

#47

this has been discussed elsewhere before, but personally, I’d prefer something like an additional 8 scripts that aren’t linked to trigger inputs.

without inline commenting or the ability to create variables with meaningful names, I think having scripts longer than 6 lines is just asking for trouble.

9 Likes
#49

I disagree. I don’t think they are separate at all. They are two approaches to the same or at least a very similar problem. Needing more space to express something in code can be solved both by moving some code to a different script and by making the script longer. In terms of readability, most programmers agree that functions should be concise, which could be seen as an argument for keeping a limitation on script length and instead solving the issue with more scripts that can act as functions to be called for a specific purpose.

This is another thing I disagree on. There are good reasons for limiting the length of a script (which is why there even is a limit to begin with - this was not an arbitrary choice). Limitations are a useful thing and imply a certain type of use. It is of course possible that this limitation should be taken away now that the ecosystem has evolved, but I don’t think it is as simple as you make it out to be. I think this should be well-considered.

Personally, I’d prefer to leave the script length as is. I currently have six devices (er-301, 2x txo, 1x txi, just friends, w/) connected to my teletype and rarely find myself in a situation where I have trouble fitting all the code I need into scripts. I could see use for some additional scripts, but I think adding extra lines to scripts would negatively impact the navigation in scripts. Of course, I wouldn’t mind a somehow configurable option (although I don’t think something like this exists, yet?).

9 Likes