(Teletype) expanding scripts: length and amount

Longer init script would be enough for me. :smiley:

makes me sad that nothing really came of this

i thought the ideas exchanged were some of the most exciting i’ve ever heard of within this community

mabye the time wasn’t right for some reason

4 Likes

I’m so excited about the other updates that I don’t mind if this comes sooner or later. :slight_smile:

2 Likes

Definitely agree. I’d also like to voice that this thread was a super exciting to me and hope that something will come of it.

1 Like

I had the chance to buy a second hand Teletype module two months ago, this module is amazing and now that I’m playing with the grid ops I’d also like a longer Init script if that’s technically possible. The 8 scripts and 6 lines per script limitation is a good exercise (like when I decided to choose a 2x84 hp case instead of a 2x104) but with the grid ops yeah a longer Init script could be useful. I also have two TXo+ and an ER-301 so the Teletype is now a major element of the case. A frustrating thing that I’ve encountered is not being able to write IF and L on the same line, I have to call another script.
IF X: L 0 15 PN 0 I RRND 256 RRND 3638

With these PRE, sometimes I wish I could “tell” the script “ go the the next line” with a symbol like “>” when I don’t have enough space to write the conditions, haha. But the new “per script” variables are already a very useful addition.

2 Likes

I had an idea today.
Does the Teletype memory structure allow the possibility of calling scripts from another scene? I could imagine storing a bunch of init scripts or helper scripts in a scene, that’s only used to store ‘functions’ that are called from the active scene. Could pass global variables through as well.
Would certainly help with TXo setups, and grid integration layout initalisations

Sorry if thats been brought up previously, I havent read this entire thread

1 Like

I for one would like to voice support for the script line/length limitations. I am a software engineer during the day and I think the limits that the TT language has implemented are reasonable. TT User’s aren’t expected to debug or deal with runtime errors. That alone is an incredible feat that often gets overlooked. While we appreciate what we can do with TT, that appreciation is also what breeds the frustration when the limits are reached. I think that stretching those limits should be done with great caution as software is hard. I think that if I had to start employing techniques/skills that I use during my day job to write a TT script, I would immediately sell the TT.

All this to say, TT to me is an environment I enjoy living in. I think that if it’s limitations are too much for some then I would guess there are probably more adventurous coding eurorack platforms out there that are better suited for that task.

6 Likes

Someone with just a standalone Teletype would probably be fine with status quo. Those of us with a few Telexes and a grid are having a harder time setting things up within a scene.

5 Likes

Trouble is, there is no better platform for developing grid apps than Teletype. If PD or MaxGen, or whatever else the more “adventurous” coding-platform modules can run, offered better experiences for integrating a grid into a modular rack, they’d already be in use as such. If you know of another platform for Eurorack where you can plug in a grid and just start iterating on some code, please tell us.

1 Like

the thing is, it’s not an either/or scenario. just like grid ops / grid visualizer could be considered making tt more complex, they only do if you use them. if you don’t, you won’t even see it (unless you happen to accidentally press alt-g on live screen). edit: i should clarify i’m talking about the shadow scripts concept. for others it will obviously depend on how the UI is implemented.

there is nothing wrong with limitations (indeed, self imposed limitations can be a great source of inspiration), just like there is nothing wrong with super complex dense scenes. the very nature of teletype is that it can be many different things to different people.

“If you don’t actively fight for simplicity in software, complexity will win.” i actually agree with this, but to me this is an argument for longer scripts. shorter / more efficient code tends to introduce complexity. readable code tends to be more verbose.

9 Likes

Amen. I say let the code golfers have their fun (keep lots of short OP aliases and “compound function” OPs) but some breathing room would be healthy. Grid OPs still make me go cross-eyed with the number of argument compared to other OPs, but I appreciate the necessity of that density for fitting on one line.

Shadow scripts are still my favorite conceptual approach. Let “scene calling” be used for modular scripts rather than simply MORE scripts.

@jimi23 yes you can call a new scene and maintain your existing INIT. I think we actually need a new OP or two regarding this behavior. One OP for changing whether or not INIT should run, and a variable that returns the number of the previous scene (I want to make finite state machines!). A variable that returns the number of the active script could also be useful for when calling a script from a script.

1 Like

I think norns is pretty nifty and crow will allow for a different flavor of grid app for euro which can have reallllly long scripts.

I’m not in favor of adding much more complexity into Teletype and share the same sentiments as @hankyates

The shadow scripts idea was probably my favorite one that has come out of this discussion.

4 Likes

Read through this entre thread, lots of great ideas here!

What’s the status of all this? Are any of the suggestions making their way into the coming firmware?

3 Likes

From my understanding, nothing major has reached beta (except I think a new version of SCENE called SCENE.G that doesn’t overwrite grid button and fader state?) @scanner_darkly has plenty of fish to fry, so without more active contributors I wouldn’t hold your breath.

Ok, thanks! Totally understandable and cool, but still a bit of a pity…

to confirm, i have no plans on working on this.

Had my TT for about a week now and I’m starting to see both sides of the discussion here. I can easily envision myself wanting expanded capability to support I2C devices I own as well as having some use cases for expanded scripts… but I don’t want it to be a weak-ass replacement for a laptop and Expert Sleepers device. I have those and there’s a reason I don’t reach for them first.

Just throwing a different idea against the wall: what about an actual hardware expansion? Something that focuses on the UI needs of managing and navigating an expanded scripting space. I’ve had an Er-301 for about a week now and the way it uses two screens and button groupings for general and focused editing has already created some nice muscle memory.

The most basic idea is a 128x128 OLED with a couple buttons that enables some extra keyboard controls when connected.

EDIT: this is probably too far out there, but a debugging mode like javascripts Redux console in Chrome is an interesting thought to me at the moment.

Twenty characters of SCENE.G! :+1:

It’s late here and I’m sure I’ve missed something, but I don’t see SCENE.G in the manual :slight_smile:

Thought a little bit deeper about it and came up with these identity statements:

it contains state
it navigates state
it recieves messages and logs them
it maps these messages to named regions of code
it creates new state
it shares state

SCENE.G is available in the current beta and allows calling another scene without resetting grid controls. This addresses the needs of people who’ve been bumping into script limits when using grid ops to design custom grid apps on Teletype. There has been some discussion and work done some time ago toward adding a UI around USB disk scene storage, to my knowledge it hasn’t been worked on in some time but I’m interested in looking into it again (at some point). You may also be interested in what is known so far about crow. Exciting times!

1 Like