#200

i’d like to reiterate what to me is an important point. for all of the options discussed how will navigation work? it feels this aspect is neglected a bit in the discussion, but small things are super important for usability when it’s something you will use often.

not just what shortcuts should be used, but typical use cases - debug a triggered script, make a change, continue debugging. what presses would be required?

8 Likes
#202

i’ve had a thrilling time catching up on this thread (somehow accidentally muted it weeks ago)

there’s almost too much to reply to…in reverse order:

@freqout idea for bi-directional tabbing is gold, please consider adding eventually
@laborcamp chiming in with others because I especially love your last mock-up for shadow scripts
@scanner_darkly please share a build w/ shadow scripts when you have time…you seem to have the idea completely fleshed out and there is demand for it from many of us

@knightswhosayneve i hope you were not totally put off, kinda wish I had seen your posts as they were happening

it would be easy to get frustrated by talk about what fits the “spirit” of teletype when it’s a community driven project

some of the folks do have a personal idea about what that means when they say it
when i think of it i’m mainly influenced by previously stated feelings of @tehn

he’s welcomed contributions from plenty of dedicated and creative people (eg @scanner_darkly / @sam / @sliderule) and the environment is more vibrant and enjoyable than ever because of their collective work…but a few times he has weighed in on features to express whether they fit his original vision/intentions for the module

i don’t think there’s anything wrong with that
i also don’t mind if he’s occasionally challenged or prompted to reconsider his stance by members of the community (whether they develop for tt or not)

11 Likes
#203

now to my personal feelings on the topics presented above…
seems like we have multiple strands in this thread

  • i2c jockeys who feel a bit contricted

  • grid op users

  • those who wish for more variables

  • those who wish for more space

@ngwese wisely noted that certain solutions may disturb (destroy?) the stability of the whole system

i really wish there was a way to make several solutions available…allowing the user to decide which ones fit their workflow and musical style

selfishly i want to try both shadow scripts AND timeline but i doubt i’d use shadows once TL is ready (others may feel the opposite)

if only a 1 or 2 things can be done to solve the issues with space I’d rather have TL and FN than additional scripts

somehow both those tools feel like they’d fit my music already, but would likely change my approach to coding and allow further exploration with live mode / Grid Ops / Just Type / With Type / Ansible and any future weirdness

2 Likes
#204

There’s a solution to that, and it’s implementing the shadow scripts now in a way that allows them to be replaced by the timeline later on without breaking old scenes. See my post above.

1 Like
#205

I’m not opposed to your idea but am finding it difficult to reconcile in my head
cause i see shadows and timeline as conceptually very different

(unless i am totally misunderstanding how each mode works)

if indeed shadows scripts get replaced by TL i would not expect backwards compatibility

1 Like
#206

You’re right, I messed up the wording on the backwards compatibility part (I just edited the original post). Timeline wouldn’t be limited to 8 lines and would have extra operators, meaning new scenes wouldn’t necessarily work with an older version.

The common characteristic between shadow scripts and timeline this proposition is built around is their ability to call a block of code at a specific “address”. It’s true that these blocks are represented in different ways; shadow scripts puts them in different windows; timeline strings them one after the other in the same window. Because of this, timeline naturally allows us to think of them in a sequential manner (also because it has methods dedicated to this kind of use), while it isn’t true of the shadow scripts.

1 Like
#207

I’ve thought about this quite a bit. My previous rambling is here: (Teletype) Pre-2.1 Operators and Features. Rephrased and more focused version below:

I think physicality is an important part of the Teletype coding experience. Each snippet of trigger code is connected with a physical place on the instrument. (I would even argue that the metro and init scripts have places that are easy to visualize.)

This physicality performs magic in the brain when developing patches in that we can easily organize and remember where everything is. You can literally feel this when you use the TT. This is why many people have exclaimed that coding on the TT is vastly different than coding at work or slogging on some firmware.

This makes sense when you think about memory palaces - the technique that the ancient Romans and Greeks used to remember vast amounts of information (https://en.wikipedia.org/wiki/Method_of_loci). It is my hypothesis that the TT is providing a memory palace like assist for our coding. That is why it feels different. That is why it feels easier. That is why we can concentrate on concurrently making music and coding so fluidly.

I would recommend caution in moving away from this metaphor. While the idea of an extra-long scratchpad of code that can be executed by calling line numbers or function names is super enticing, this just breaks the mnemonic magic that is subconsciously at work in the instrument. The thought of remembering line number ranges or arbitrary function names feels antithetical to the core metaphor of the device. Line number usage seems even more troubling in thinking about what happens during insertion and deletion.

This is why the shadow script idea feels the most right to me. We can have a single shadow script that sits underneath each prime script. A key switches you between the two. Another key combo swaps them (shadow becoming prime and prime becoming shadow). Operators call each individuality and programmatically swap them.

This gives us a little more room but doesn’t break the fundamental construct that the device is centered around. It also keeps the instrument’s beautiful, beautiful limitations. If you need more flexibility - grab a second TT. If you want endless functionality, grab a computer. :slight_smile:

24 Likes
#208

perhaps this thread is a pivotal moment for teletype. teletype grew to be many things to many people, precisely because of its open ended nature. so at this point how do we define “the spirit of teletype”?

and if we talk about minimalism, it will also mean different things to different people. say, to me chaos and turtle ops go beyond minimalism (i’m trying to be very careful here, so i most certainly don’t mean this as a criticism of either, simply that they are outside of what i would consider the minimalistic nature of teletype. so are grid ops).

… as i was about to try and explain what to me is an important difference between shadow scripts and timeline @bpcmusic did it better than me :slight_smile: i’m going to try and stay out of the discussion, so i’ll just say this: think of the strength of both approaches. i don’t see them as mutually exclusive. i think timeline is an exciting proposition. tt is an event processor / producer. i thought the original proposal for timeline was following that spirit, having this script roll which represents an event timeline, which is a natural way to compose and express, being able to jump to arbitrary points - this to me is an exciting tool, and one that fits the spirit of teletype. but using it as sketch pad or a place to host anything that doesn’t fit in scripts feels like a hack, a workaround that doesn’t take usability into account.

at the risk of sounding like a broken record, consider typical use cases:

  • you have a scene developed. you decide to add something to it, but your script is already 6 lines long. what do you do at this point? you can copy paste it into timeline (so, select, copy, navigate to timeline, paste, go back to script, add a call to the timeline). or you move this line to another script and just call it. which is faster? which would you rather use?

  • you have a script that calls something from timeline. you need to change something which requires making changes both to the code in timeline and to how it’s called. how do you jump back and forth?

without having a way to jump to relevant part of timeline quickly i would consider both of the above workflows not user friendly. one way perhaps is to provide a hot key that allows you to jump to that specific place in timeline and back.

this is not meant as a critique of timeline. but this discussion is not really complete if we don’t consider usability aspect.

11 Likes
#210

@scanner_darkly suggestion of being able to jump to a timeline entry from the place it’s being called with a hotkey is excellent. Navigation through timeline could also be made easier by providing a way to jump to the starting point of entries with shift + up/down arrow.

It’s already been brought out by @Starthief, but I think timeline can lead to much cleaner and more readable code if we allow creating tags for it’s entries. By that I mean each line would have it’s dedicated number but also could have it’s own name. It would be similar to functions in a way. Say you named an entry line NAME, you would then call it using #NAME or through it’s number # X. This does not confilct with any operator names as they would be preceded by #..

Similarly, I think it would be very nice to be able to declare our own variables. Say we reserve the character _ for this, and have any sequence of character starting with this be a variable. The first time it is set (_NAME X) makes it a valid variable with a value; any succeeding get (_NAME) will be valid. If a get is issued without the variable being declared first, it defaults to 0. This might not be possible technically as more (how much, I don’t know) complexity involved in this. But this would again make code more readable.

#211

Well, if we’re thinking about the timeline as a collection of functions, I’d rather have a global library of things that can be used by any scene. These kinds of things tend to be large, a lot of work, and fragile when you start trying to move them around.

#212

as much as i’d like to have a shared library for all my scenes it would make scene sharing impossible, and scene sharing is a super important aspect of tt ecosystem to me.

there is a feature suggested that could provide a suitable workaround - being able to copy scripts between scenes.

5 Likes
#213

Sharing would work fine if the library functions were shared too. :slight_smile:

But honestly, I like the shadow script idea better because it will result in less clutter … especially if the init has a shadow for its shadow :smiley:

#214

as long as it’s confined to the scene itself. but sharing a scene + global function library would not be feasible (it would replace your own library). but with being able to copy scripts from another scene you could just dedicate one scene as your global library, and the scene you share would not have a dependency on it and be still self contained.

2 Likes
#218

It bears mentioning that those are many volunteer hours.

13 Likes
#219

I urge you to calm down a bit and then re-read the discussion above. It’s very hard for me to see how you came to this perception of the situation.

Right after you asked what that person thought the “spirit of teletype” was, they answered and explained (well put if you ask me):

Several users as well as tehn himself have explained what ideas were important for the conception of teletype and thus represent the general spirit behind the design decisions. They have also outlined (better than I could have) why it may in fact represent an issue to remove limitations, particularly for the guidance of new users and less experienced programmers.

I understand that it can be frustrating to see a bunch of people argue for the exact opposite of what seems like the best solution to you, but I don’t think you’re being fair in your judgement of the situation.

I think this is the least elitist place I have so far found on the internet. Anyone who wants to partake in a discussion is actively included and everyone seems to try their best to keep discussions calm and polite.

6 Likes
#220

I think it ~can be~ an important part of the instrument. I don’t use the physical trigger inputs very often, I prefer to build scenes that self-reference and fold in on themselves into code origami. I don’t have a very large system and don’t have a lot of fun-to-control trigger sources available, and being able to call scenes from other scenes is what made me actually gel with teletype. I can code more fluidly because I’ve spent hours and hours and hours messing with it, not necessarily because of spatial dynamics. Line number usage is at work all the time with the pattern matrix.

surely this implies a sin of even greater gluttony? :wink: I’d rather put
$480 towards a dev to create a branch with additional scripts.

re. teletype as architecture
i’ve been handed a really incredible set of building tools. i have at least 7 different choices of building material in infinite amounts. amongst these tools and items are 8 doors. ive also been handed a law- because ive been handed 8 doors, i can only have 8 rooms. a pleasant house is easily within reach. but i have had to learn to enter into every creation by first fully taming my thoughts of what i want to see. a disappointing starting place, though i suppose skyscrapers do litter.

the palace isnt sacred until its built~

did anybody play simtower?

simtower-the-vertical-empire_19

#221

Love the idea. It would fit right into my current practice to set up a param knob to act as a meta param that swaps several scripts with their shadow scripts as a compositional/performative thing. I’m curious, do you have some draft syntax in your head here?

On physicality: I’ll say that I will often times just externally trigger 1 or 2 scripts, and then have those call other scripts (which aren’t physically triggered) with a bunch of EVERY's as a sort of clock division-type thing. I do not feel that this is counter to the “spirit of teletype”, as I could easily re-architect those to utilize external triggers instead.

Which leads me to something @infovore said that I’ve been thinking a lot about in terms of this thread

This is one reason why shadow scripts appeal to me. I want things to be very simple to move around and rearchitect. I do not think rearchitecting a teletype scene should feel like the undertaking of excising some piece of code in an enterprise software project. I don’t think timeline goes too far in this way, but the indirection/abstraction it enables definitely increases the risk of it’s use becoming more static and less close to modular synth patching.

Also, I definitely think any sort of solution should consider future portability as @simondemeule has mentioned a couple times.

5 Likes
#222

I got to say that at first I was very excited by the shadow scripts idea that appeared to me as a nice way to expand the lengh of initial scripts. But the more I think about it the more I feel that TIMELINE would be a better choice as it not only expand an existing functionnality (it solves the need for longer scripts) but it add a new way of thinking and organising the scenes. $$ doesn’t seem to push the TT concept further. So in short I see $$ as a way to enhance my scenes and TL as a way to explore new paths.

3 Likes
#223

+10,000,000 for Shadow Scripts. :slight_smile: It solves the “More space” dilemma while keeping things sorted in a way that is instantly familiar.

7 Likes
#224

Personally I like the shadow scripts much more than the timeline. It is unclear to me how editing the timeline would affect pieces in script that reference it. I’m a bit confused about the shadow script proposal though. Do they allow more than 6 lines? I hope so! If they are line limited than I don’t see much point.

What about patterns? They really go hand-in-hand with additional script room. I find the teletype very limiting for polyphonic sequencing now. More script room is great, and fixes some of the problem. We need more patterns too. I run out of script length now because I have to use bitwise operations to store more data per pattern. I wouldn’t have to do that if I had more patterns.

1 Like
Teletype - Programming a keyboard to send stored commands