(Teletype) expanding scripts: length and amount

[freqout]

heard a few bring up concern with the tabbing getting crowded. this is a tangent, but i often reflexively attempt to shift-tab to move back in the other direction, but obviously that doesn’t actually function in TT, but… perhaps it could? Might relieve the feeling that there is too many tabs if we could move both directions.

[ermina]

I imagine by paging down into the sscript layer and moving [ ] and then paging back up, i’d imagine being in the same spot i paged down in, rather than paging up in an “associated” script.

2 cents of opinion, to me this behavior would mean those sscripts are children of the script from which i paged down, and i would assume each script has its own children too.
That would also confuse me as paging up from a sscript would land you on a different place every time, and that inconsistency is an instant cognitive burden.

As for visual cues of being in a sscript, why not invert (colors of) the less read line, the 7th one, which already has a very different role (error messages) than the others. Or just invert the numbers at the beginning of the prompt line. They’re in a corner and i have a feeling the eye glances there automatically to help maintain a position in the mental map.

All in all the timeline feature with its “notepad on the side” (i figure it belongs on the right of I) feels more natural to me, but that is probably because of my tendency to use small areas of random papers when i need to think for a minute. I also guess it is a feature which implementation would require tons of work, hence its absence at the moment.

Would the teletype codebase be a reasonable start to learn C (assuming knowledge of basic programming) ?

[Inkwell]

would land you on a different place every time

I totally see your point, and respect it. I imagined it could be simple and useful really tho. Just keeping an index of the two layers. For example, I could be on script 3 editing something, page down to sscript 1 and alter a live coding parameter, page back up to script 3 and move over to script 8, and then page down to sscript 1 again to alter those same parameters again. I think I’d use that all the time as a live performance feature.

[misuba]

For example, I could be on script 3 editing something, page down to sscript 1 and alter a live coding parameter, page back up to script 3 and move over to script 8, and then page down to sscript 1 again to alter those same parameters again. I think I’d use that all the time as a live performance feature.

I feel like this use case is a pretty strong argument for timelines. Something that has a fully different mental model has the advantage that it can’t be a slight mismatch for another mental model. And as I understand timelines, they wouldn’t be a lot slower than this.

[tehn]

timeline can have a hotkey for jump-to-line (and other nav helpers) for example

it’s worth drawing on the legacy of features from text editors and IDE’s (etc)

[bushel]

just now reading this topic you linked, sorry about interjecting my thoughts prematurely.

(Teletype) Pre-2.1 Operators and Features

adding 8 more scripts is inelegant. it breaks the form in many ways. no physical triggers would require a weird keystroke hotkey for execution (ie mod+F1) tons of extra paging-around in EDIT mode, short of adding more modifier hotkey jumps the FN concept is runtime defined. so you can change what the functions do using other code. you can’t do this with more scripts. FN is a needed and helpful shortcut for long lines. chaining SCRIPTS together is inelegant. a better solution for long multi-l…

I wanted to respond to this in particular.

-additional scripts wouldnt be any more inelegant than is already established. two current scripts don’t have associated inputs.
-i don’t believe that chaining scripts is inelegant. this posits that there is a right or wrong way to use scripts. i deeply enjoy chaining scripts together and building webs of inter-reference. no, my code is not fit-for-share and doesnt exist for very long, but nothing does in modular-world. its magic to build a system that you can get lost in. elegance can be ensured in syntax and interface of the tools and is the end users responsibility to follow through with organization of their building.
-the proposed timeline/alias ideas are rad
–i do think that its worth responding to the amount of people thus far that have asked for a relatively simple thing: more room, likely via a conceptualization of more scripts. isn’t that what the community of a community-input-grounded module is asking to see with those requests, or am i misunderstanding?
–it is very worth considering what can actually get done in a reasonable timescale vs not, given the rapid expansion of the i2c ecosystem. is incrementing script count a relatively simple thing to do under the hood vs implementing a vision of the timeline/aliases? hasty, hasty, though.
– the current semicolon usage is “maximal jam” - that pandoras box is open.

I’d like to also say that I love this community and the people that have worked to make tt a reality in the way it is. I have a lot of respect for tehn’s vision and creations. id like to thank the academy. i communicate in a very direct manner and am not grumpy. id invite tehn to please jovially throw my input in the trash. tone in this forum is very much on my mind and i do not wish to be accused of being antagonistic or disrespectful, just responding.

it can, as someone who rarely speaks up but often reads these threads very closely, feel like a decision is forced. there is a shyness-inducing dynamic between people who are able to actually integrate and create realities vs those who can not speak that language. there are things that have been fully integrated into newer tt versions that have behavioral and aesthetic aspects that bother me. i had put forth no effort into voicing my opinions during the development because i was not confident enough to poke my head in, and think about it often. i appreciate greatly that the things have been integrated and exist now.

[tehn]

and i appreciate your feedback and glad you’re speaking up. that’s why we’re all here

it’s very important (as many of the generous contributing coders have said in this thread) to acknowledge that open-source is a gift. yes, it’s community-driven, but those mainly driving are those who put the massive work in. it’s hard to convey how this graph translates into hours, but check it out: https://github.com/monome/teletype/graphs/contributors

most of the changes were motivated by what the person writing the code wanted to see, and then let those ideas get shaped in discussion here. and when changes get added to the release we all benefit.

regarding my position on further changes-- i’ve already tentatively supported the shadowscript idea provided the UI can be proven.

it’s natural that a software-based system grows and changes over time-- what’s difficult is maintaining a design philosophy and retaining the clarity of the original vision. it’s worth rewatching https://vimeo.com/129271731, the very foundational ideas of teletype. they weren’t easy decisions, and i do feel like it’s a pretty remarkable minimalist achievement— introducing maximal open-endedness while presenting a use method and environment that doesn’t bury you. something that actually gets non-coders enthusiastic about scripting with synths. everything feels obvious in hindsight, but making Teletype was a gamble— initially most people didn’t get it (and it still doesn’t have a huge following— just a very passionate one.)

i’m rambling, but in short— i’m trying to stay true to the original vision. we’re simply having a conversation here about needs and potential solutions. so many good ideas have come from this process. everyone just needs to stay chill and realize the process will unfold, and things will be good.

[Starthief]

My personal take is that the concept of shadow scripts doesn’t seem very distinct from scripts 1-8, except that:

• they don’t have hardware triggers
• should they have keyboard shortcuts to execute, edit, and mute them?
• should they fully supported by SCRIPT, LAST, INIT.SCRIPT, @SCRIPT?
• should they have their own versions of O, EVERY/SKIP, etc.?
• the interface needs a new mode for their editor, and keyboard commands to enter/exit that mode

It seems like a kludge somehow, and just having scripts longer than 6 lines seems simpler. Maybe in practice, it’d be fine, I just have vague philosophical misgivings as someone who’s only owned TT a couple of weeks but is a career code monkey

But I’m much more in favor of the timeline. It solves the length problem while also allowing more readable code.

Take this thing I wrote in my first couple of days with Teletype, which uses patterns to store Euclidean settings and status:

X PN 0 1
Y WRAP PN 0 3 0 SUB X 1
Z SUB Y PN 0 2
IF ER PN 0 0 X Z: TR.P 1
PN 0 3 ADD Y 1

What if I could write this instead?

IF ER #FILL #LEN SUB #STEP #ROT: TR.P 1
#ADVANCE

I’m using two script lines to do the work previously done in 5, and it’s easier to read. And I could tack a #DO_MORE_STUFF to the end to execute more script code if need be. All of those are defined in the timeline, out of the way where I don’t have to worry about them much.

[jasonw22]

everyone just needs to stay chill and realize the process will unfold, and things will be good.

This is just good life advice, in general.

[misuba]

Timelines seem to have that monome/Mannequins flavor of solving a lot of different problems all at once, really elegantly, but implementation is king. If a person who can do the codes does them to shadow scripts, I will use them with gratitude and gusto.

[jnoble]

As a professional programmer, I like (no, love) the timeline proposal in principle … but I don’t know how it would work in practice with an open-ended bunch of code: we’d almost need a search facility (inelegant) or a function/index list (better but sounds cluttered) to navigate it. I also don’t know how non-programmers would interact with it … but I would have a blast.

But justice delayed is justice denied: if the timeline is a long way off, I’d suggest pursuing some combination of the features proposed above. From my perspective as an owner of seven(!) I2C connected peripherals, anything that allows me to configure all this cool stuff without consuming precious trigger-associated scripts (or ugliness like scene switching) would be amazing.

I can work around most every other limit with clever programming, creative use of the patterns (I just think of them as four arrays with a nifty display feature), etc. A few more ops outside the scope of the current discussion would be welcome, too, but none of them are as pressing as the configuration issue. Having more general purpose code space would of course be welcome (especially for grid ops, I gather), but it’s less pressing in my view.

I’ll join the others in loudly applauding the people doing this work, I continue to be amazed at how Teletype has advanced over the past year!

[jasonw22]

we’d almost need a search facility (inelegant) or a function/index list (better but sounds cluttered) to navigate it.

I still need to reread the original timeline proposal, but I remember that navigation was my hangup upon first reading back in the day. I was having a difficult time imagining how that would work.

[grey]

I’m still really in support of the shadow script concept. The challenges in designing and organizing the information in parallel to the existing script system seem like a really low barrier to accomplishing compared to what needs to be wrought for the timeline proposal. There is a probably a happy medium where the features can make sense with each other, but in the near term, I’d love to see a version of shadow scripts move forward.

[laborcamp]

Few possibilities for shadow scripts, based on various scenarios discussed, and some other approaches. Mainly to have some visual reference for further discussion.

—Inversion of the whole screen would be crazy in my opinion. But inversion of just the bottom/input line might work.
—The side line might be a nice visual continuity from other UI designs (tracker, variable monitoring screen etc.) but don’t know if that is too subtle.
—The inversion on just the script number seems totally simple and effective.

Thoughts?

[jnoble]

That is super cool.

Combining the left ruling line of the bottom left example with the inverse script number as in top right would flag it nicely.

[bushel]

—The inversion on just the script number seems totally simple and effective.

this! 20 characters 20

[laborcamp]

Like this?

[dan_derks]

oh dang, that’s pleasing

[jnoble]

Like this?

The line seems to draw the eye down to the inverse script number.

[100microdots]

should they have keyboard shortcuts to execute, edit, and mute them?

You could use shift-1 to fire Script 1 off and alt-shift+1 to edit. Is there a mute shortcut available in 2.2, I don’t recall seeing that on the command cheat sheet.

should they fully supported by SCRIPT, LAST, INIT.SCRIPT, @SCRIPT?

From a users perspective I would expect that functionality, maybe with a slight variation on the name but I think the only required would just be SCRIPT.

should they have their own versions of O, EVERY/SKIP, etc.?

I think they should share the O and definitely have EVERY and SKIP.

the interface needs a new mode for their editor, and keyboard commands to enter/exit that mode

I think I like the page down idea the best. Making a fourth stop when using the tab button wouldn’t be a bad way either. You could even move the I and M scripts to that row since they don’t have hardware inputs.

As for the function or timeline ideas, I think those would also give you new and interesting ways to expand compositions. I prefer any of the above options over making the scripts longer.