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

In a World of distraction, the 6 line limitation might be the biggest appeal of the TT for me.

2cents

11 Likes
#51

The SCRIPT operator makes it possible to create bigger, more complex scenes where scripts can be split up into different parts. The grid operators also rely on calling scripts on interaction. The annoying thing that comes with that is that the scripts you dedicate to them use up your trigger inputs without making use of them (at least the vast majority of time). From this perspective it would make sense to add in an extra 8 or 16 scripts that don’t have an associated trigger`input. But I also think too many of them would obscure navigation. 16 would be challenging to use up, but I actually see cases where that could happen (grid ops with pattern sorting algorithms).

I think the length issue is better solved by the timeline feature suggestion.

4 Likes
#53

I haven’t overlooked that point and in fact I thought it was fairly obvious that I was addressing that point in particular. I think it’s shortsighted to think that such design decisions aren’t influential to all users.

2 Likes
#57

That’s why I also mentioned configuration. I think that would be a good solution if someone is going to implement that and it’s feasible.

Also, I know you’re joking, but still, I’d like to make it clear: I wasn’t saying that the idea of longer scripts is short sighted, I was saying that assuming that taking away any limitations without careful consideration because “everyone can limit themselves if they want to” is short sighted.

I still think that more scripts along with something like the timeline feature would be nicer, but adding a configuration option for longer scripts, i.e. an “expert” mode that you have to explicitly activate is something that is hard to disagree with.

#58

I think one big aspect to consider is the community-driven nature of Teletype, and therefore scenes are often shared on forums. So if others are developing scenes on Teletype with more than 6 lines, it will inevitably creep into my system as I borrow and modify scenes from other users.

7 Likes
#60

Agree. as @Starthief mentioned I would prefer an additional tab or shift + nav to access the additional scripts

Re: more vars:

With teletype, I find using vars to more often than not be an anti-pattern. If you have a script that updates a particular variable, and another script that uses that variable, It is easy for them to become bound sequentially, which makes altering trigger patterns (to positive effect) more difficult. I have found it is better to scale params/inputs with .SCALE or .MAP to what you need the data to be and call directly (not always the possible or best solution, but I tend towards it)

#61

Is it worth stating the obvious reminder that the code is open source and you can have longer scripts, or more script or whatever if you’re prepared to do the work? Me, I like the 6 line limitation, but occasionally could do with a few more variables.

8 Likes
#62

I’ve not got the right setup to compile it at the moment so I cant check, but would editing these 2 settings in src/state.h in the github repo magically make dreams come true?

#define SCRIPT_MAX_COMMANDS 6
#define SCRIPT_COUNT 11
#63

Just adding my vote for keeping the 6-line, 8 script limit. I love it.

4 Likes
#64

The thing is, it’s not just a matter of incrementing that variable. You’d have to make some kind of scrolling mechanism.

1 Like
#65

My vote is to add an extra Op

POWERUP

or whatever, that just changes the SCRIPT_COUNT from 11 to 99. You could call it from the I script. That way, people who don’t want extended script numbers don’t have to use it. The people who do, can.

I may have a go at the weekend. The problem is, I’m so close to finishing a project on my main machine that I don’t want to mess it up by installing new compilers. grrrr. I’ll see what I can do.

Might not work at all of course. Just a guess.

#66

Agreed. Not if you are just increasing the number of scripts though.

#67

Oh I somehow didn’t process that. To be fair I don’t know.

#70

I’m repeating myself a little here but I just want to add my voice in support of the 6 line limit. It isn’t just as simple as ignoring extra features when using tools like teletype. The limitation ensures that scripting is well considered and purposeful. I really believe that working with limitations is one of the key things that most make us creative as musicians. The fact that there are extra lines available will unavoidably change how we interact with TT as a tool. Like @x2mirko says, that change should be well considered. TT is a surprisingly elegant and immediate module for a programming terminal… it would be a shame if some of that was lost.

Extra scripts - I feel less strongly about and have certainly found myself in situations where it could have been useful. But if I had to choose now, I would keep it as it is, for the same reasons as above.

6 Likes
#71

It’s rare anything is ever that simple :smiley:

Not an option for me right now unfortunately. I can dig out an older machine when I return from my travels and try it on that. The original coders must have set it as a constant for a reason rather than peppering the code with “11 scripts only” code. Thats what I’m clinging to anyway :smiley:

Why is it open source? For modification surely? That is a deliberate design too.