#18

calling another script is an option, but you loose a gate input by doing so…

#19

I was able to do it by using note values and calculating things separately (in Ruby, some leftover scripts from my monome 64 days - how I wish it would connect to Ansible!). I just took my time and typed them into the pattern tracker.

See, I’m a newbie, starting to get the hang of shorter code and calling things.:baby: But as a programmer, I do long for more control, loops with multiple lines, arrays, longer scripts. In the write preset window, I can scroll many lines, so the esthetics argument seems a bit silly to me.

I do love the Teletype but it’s kind of a shame it’s so limited. I start to appreciate that it’s opinionated, and I have to work through puzzles each time I want to accomplish a new project - which leads, of course, to happy accidents :slight_smile:

Maybe I’ll take a look at the firmware repo and get inspired for a pull request? Or perhaps there’s limitations due to memory and hardware?

Thanks @scanner_darkly for the suggestions!

1 Like
#20

You should consider making your own custom operators if there are things that you want to do regularly that could be abstracted/factorized that way easily…

1 Like
#21

i came to appreciate the limitations somewhat, imagine coming back to a 100 line script later and trying to understand what it does / edit it on teletype. i do think though that the limitations often force you to make things less readable. personally i’d love to see more scripts and/or longer scripts, more variables and pattern banks (arrays would be nice too, patterns do cover that territory somewhat though). tt is a balancing act though, so power vs simplicity has to be carefully considered.

if you’re comfortable with setting up the toolchain i’d totally go for modding it yourself, there might be some memory/hardware limitations (tbh not sure how much room we have), i’d just try it and see if it works.

monome 64 - does it not work with ansible at all? not sure if all editions do. if it’s a model supported by libavr32 you could also use it with teletype with the upcoming 2.3 version (you do need to power it externally).

5 Likes
#22

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

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.

@scanner_darkly

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

Isn’t that what the tracker patterns essentially are?

that said, I always wish for more variables!

1 Like
#25

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.

#26

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 :smirk:
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
#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