#102

Yup, 9 times out of 10, I run out of lines/scripts when I’m calling other scripts from I because I’ve run out of room in I.

#104

Page up and down also helps with maintaining a spatial mental model of script length and position without requiring line numbers. I like that suggestion for scroll behavior.

1 Like
#105

they would also work well as temp storage. i often find i want to try a variation but don’t want to lose what i already have. having them easily accessible would mean it’s easy to copy lines between the 2.

what would make it especially useful is that they would get stored with the scenes too.

2 Likes
#106

The growth of support for external modules certainly merits consideration of how to relieve pressure on scripting density. Not that I have any real scratch in this game other than being a user, but as they are an active developer for Teletype, I feel like @scanner_darkly’s proposals reflect deep consideration of the way TT already works and why.

I’m all about their suggestions. +1

2 Likes
#107

I really like your vision for the shadow scripts.

My only suggestion would be to fire them off with the same command as launching the other scripts to keep it simple. The shadow scripts could be numbered 9 through 16 or by putting a 1 in front of each one, i.e. 11, 12, etc…

Now, would this be the wrong place to talk about more patterns? :slight_smile:

#108

i would be afraid to hide them too much (they need to be fairly easily discoverable but not get in the way).

they should not be included however when scrolling through scripts with [ and ], i added that to my post.

2 Likes
#109

this would lose the association between regular scripts and corresponding shadow scripts. i think it’s more intuitive when you think in 8s - 8 trigger inputs, 8 scripts, 8 shadow scripts

2 Likes
#110

this would lose the association between regular scripts and corresponding shadow scripts. i think it’s more intuitive when you think in 8s - 8 trigger inputs, 8 scripts, 8 shadow scripts

Fair point on the 8s. Is there a reason you went with # as the operator as opposed to something with S or $ in it?

#111

But we’d need some way of differentiating between a shadow script call and a normal script call in the grid ops. Unless we default them to shadow scripts? Which would make sense I guess.

1 Like
#112

As far as I know it’s one of the only single character op names that are still available (which is a thing worth pondering over too).

#113

no particular reason, just seemed like an intuitive choice. it might have to be something else though as # is a special character (it’s used to separate scripts in saved scenes). both S and $ are used already.

edit: SSCRIPT and alias $$ could be a good option. which would make calling a shadow script from its corresponding trigger script look like $$ $ :slight_smile:

i thought for grid ops negative number can indicate a shadow script.

2 Likes
#114

$$ is great: it’s descriptive (shadow script), short, and doesn’t use up our precious #.

That feels a bit weird to me. I don’t have a grid myself and haven’t played around with the grid ops yet, but I imagine that the vast majority of the scripts called by grid interactions are only meant to be called through grid interactions and not trigger inputs; a shadow script would be the default case. In a case where you’d want to trigger it through the inputs, you could simply call that shadow script from a regular script. This would also allow differentiating the source of the script call, allowing different routines to be run accordingly. Of course you’d still be able to do this with what you proposed. My proposition also has the drawback of potentially wasting a script in a non-default case. This is really just siding with simplicity of parameters.

#115

There is one aspect of the script length discussion (separate from that of desire or design) that I think is probably worth touching on.

Stability.

The heart of the TT hardware does have limits. Executing each of the OPs in each script takes a small amount of time. As the number of OPs per trigger event goes up the likelihood that another external trigger (or metro event) will arrive before the current script has finished executing goes up. When lots of different concerns start to overlap (running ops, updating outputs, updating the screen, talking to other i2c devices, etc) it can be really tricky to keep things stable and humming along nicely.

I can’t say where the true limits may lie (in lines per script or number of scripts). Like many things the answer probably depends a lot on what we all are doing with our devices. The true limit may be higher than were we are now. The cost (in people time) of finding that limit could be much higher than implementing the change in the first place. Several people (@scanner_darkly, @sliderule, @sam, and @bpcmusic in particular) have been extremely generous with their time - helping to expand the TT universe, triaging problems, fixing bugs and generally committing to seeing things through.

Which ever way things go (keep it the same, make a change) I hope we can be mindful of the time commitment required to keep things stable now that the community of users (and usage) has grown large.

9 Likes
#116

i do use triggers sometimes even when using grid (can lead to some interesting unexpected results). but you raise some very good points, i will think about this. the downside is - shadow scripts are less accessible, and old scenes will need to be migrated.

very important - thank you for bringing this aspect into the discussion.

1 Like
#117

This is a good thread. I often run into script length limitations myself and I support the notion of the shadow scripts. One thing that was brought up was that the scripts were tied to inputs. I don’t have every expander but I do have a TXi and er-301 and managing the IO with the current limitations can be difficult. Is there a way we can add scripts based on i2c expansion/population? I don’t have any concrete ideas how I would want that to work.

Overall, while I support them (and absolutely longer I and M scripts), I would prefer to set a dedicated variable in the I script (like expanded_mode 1) to allow for more scripts of longer length.

#121

teletype is an open source project that gets developed through community consultation. i don’t think it’s fair to say that any decisions are forced.

3 Likes
#122

So the page up / page down thing would be a nice solution. It would not change the actual workflow.

Also I think the $$ should not be triggered by the trigger inputs so we could if needed call them from an unrelated script.

@scanner_darkly Have you any thought about doing the same thing for the init script?

2 Likes
#123

Shadow script does seem like a potential appropriate compromise, and I have absolute faith in @scanner_darkly’s approach to TT. However I do feel @saintcloud’s concern for adding a 4th page onto the tab cycle. Even if it’s only 4 pages, it’s a step away from the simplicity and immediacy of the interface, which is key.

@martinmestres Do I understand right that page up/down proposition would toggle between the standard and shadow scripts? I suppose a potential risk is that a user may accidentally code in the shadow script and find it not responding to a trigger. There would need to be a strong visual cue to make it clear which you are editing.

3 Likes
#125

I also find the timeline proposal much more elegant.

Individual timeline entries could be used the same way we are using scripts as extenders, only they would not limited in length (a single timeline # can have multiple lines). This would make it possible to comment our code properly, and would solve the problem of using up scripts with trigger inputs for purposes that don’t require one. It would make sense to have the grid operators trigger timeline entries directly. It would be fun to program with; it kind of feels like assembly code in a way. Not only the timeline would provide a new way to structure code, it would also provide us something unique; some kind of huge script we can navigate around line by line and execute sequentially from other scripts.

4 Likes
#126

I am glad this topic is finally getting some real trackition here!

I don’t see anything forced though. This discussion is what makes the forum great and keeps the creative energy fueling the further growth and development of ideas AND instruments.

My thoughts;

The proposed shadow script set idea is great. I agree that a solid visual cue will be needed to designate that set. And yes, those would only be executed from within other scripts, with no direct connection to the physical inputs.

The scripts can remain 6 lines. However the Init and W scripts do seem to need more room, so these either have their own shadows or are extended and scrollable.

Along those changes I would love to see some addition to the available variables. I suggested using double characters (AA, BB, … ZZ), or number (or letter) combinations ( V1, V2, etc. or VA, VB, … VZ).

Lastly, I do recall the timeline idea mentioned, but don’t recall specifics, could someone link the description of it from @tehn ?

I think the above addition/expansions stay well within the ‘spirit of teletype’ and I hope they find a way into future firmware in some shape or form. The continually expanding i2c family alone warrants this development, and with hundreds of commands now potentially active this way, a more expanded set of scripting capabilities feels like a necessity.

2 Likes