The [something] of Teletype

Monome
#12

Problem is… the Teletype language is based on Forth, and Forth is a bit of a “write once read never” (WORN) language.

Admittedly Forth is even worse as it’s reverse Polish notation (RPN), rather than the Polish notation that we use.

We get away with it’s unreadability because the scripts are so short. Imagine a 500 line long Teletype script open in your favourite text editor! To go up to that level we’d have to start moving towards adding brackets a la Lisp, and Lisp is a fundamentally different paradigm to Forth.

Things of interest about the Teletype language:

  • Forth (RPN) itself is extremely light on memory usage. Internally our Teletype code (forward Polish notation) is run backwards (with some allowances added in for sub commands / PRE statements).
  • The grammatical rules of the language are really simple, unlike infix notation, there are no issues with operator precedence.
  • It’s easy to write a parser for the language due to it’s simplicity.
  • It runs quickly (again due to it’s simplicity).
  • The above points mean that you don’t need to be a compiler or language expert to get involved with firmware development.
  • No runtime errors, something that is not picked up very much, but the design of the language rules them out.
  • There is even a bit of functional programming in there… a MOD, (i.e. the first part of a PRE) actually takes code as one of it’s arguments (the POST, or the bit after the :).

edit: I’ve added “no runtime errors” to the list at the top, please feel free to make it more poetic

edit 2: I actually think it should go at the top of the list and be in bold

2 Likes
#13

OK. So it feels like there’s something along the lines of

Whilst the small screen and terse syntax of TT code lead towards a style based on brevity, expressivity and legibility are always more important than character count.

But, you know, briefer and possibly verified by someone who actually owns a TT. (Hanging around here as a language geek).

I think the other thing to definitely remember is: maxims can be aspirational towards what we’d like things to be like, but they must include the set of “how things are now”.

#14

So I really agree with this statement (I always preferred Python to Ruby)… but I’m going to try and make an argument against it…

The Teletype language is designed for creativity. Maybe that should be in the list at the top? If it is, I believe it to be at odds with the quoted statement. I don’t think such a statement would ever apply to any creative endeavour.

Given that the Teletype name and language hark back to the early days of computing, consider:

  • Fortran, lit. “FORmula TRANslation” (1956)
  • Lisp, lit. “LISt Processor” (1958)

This is the 1950s version of Python vs Ruby. Which would you want to use for composing music?

To my mind Lisp (and Scheme) are the ultimate in creative computing languages (and I say this begrudgingly as a Haskell coder). I cannot imagine a language less likely to have “one way to do it” than Lisp.

2 Likes
#15

Yes. I like that.

I mean, it’s literally not true of modular synthesis, the landscape Teletype exists within. And it’s also at odds with expressivity: sometimes, the only-one-way-to-do-it fails to communicate one’s intent clearly. (for instance, in _$LANGUAGE$, I use both if !thing and unless thing because to me, they are semantically different, even if they are functionally the same).

2 Likes
#16

Not sure if this is eloquent enough to add to the coda but what attracted me to TT language is the fact that the line between events and values gets very blurry

Elsewhere in the modular world values of parameters reign supreme. As a language teletype somehow makes users rethink/revaluate this hierarchy.

Put another way, rhythm and melody/modulation exist on equal footing within the environment.

This might not really make sense to anyone else so feel free to ignore :see_no_evil:

3 Likes
#17

This feels important. I believe that the reason eurorack is so interesting is because the core rules of eurorack are simple, which makes it easy for small shops to get involved. It’s relatively easy to design a new module with off the shelf commercial parts, which leads to a healthy DIY community.

I know that’s an over simplification and many modules are way more complicated, but I think it’s helpful to keep in mind.

If we commit to the language’s ease of parsing as a feature, then it encourages more implementations of the language, as you can be a language parsing dabbler and write a reasonable implementation of it. That feels like a feature and well aligned with the eurorack philosophy.

1 Like
#18

Maybe that’s the essence of what I was trying to get at. I was simply trying to find a rationale for limiting scripts to a few lines.

2 Likes
#19

Teletype’s scripting language (TTSL? :wink: ) indeed has a simple grammar that is also flexible. As such, it’s possible to write the same statement several different ways.

While it may be easy for a computer to parse TTSL, I find it a ~somewhat~ difficult task for a human. It takes concentration to simulate the stack in your head. Though there are techniques to reduce the cognitive memory load, parsing a TTSL command takes experience and/or education.

Therefore, I echo these sentiments,

because legibility is a hurdle built-in to the language.

A relatively conservative maxim from this:

Mnemonics should be easy to remember and analagous to musical intention

This guards against arguments along the line of “how is a new user going to know that X means Xylophone?” as “remember” implies “learn”.

2 Likes
#20

I like expressive. Expressive and creative go well together.

Like this too.

Perhaps “The Teletype language is designed for creativity.” becomes:

The Teletype language is designed for musical creativity.

or even:

The Teletype language is designed for musical expression and creativity.

2 Likes
#21

The Teletype language should be easy to hold in your head.

Meaning - it should flow pretty easily and feel less like programming and more like patching. Oh.

The Teletype language should feel like patching. Which it does, which I love. Which also supports the length of lines and lines per script limitations. note: …feel like patching with text? I appreciate the Teletype because it bucks the trend of skeuomorphism.

1 Like
#22

Maybe just The Teletype language is designed for expression and creativity. A colleague uses Eurorack exclusively for video work and is interested in TT.

2 Likes
#23

hah, I love that. I wonder what everyone else will think, and whether it should.

(As for your ‘what does feel like patching mean’ - well; it’s composable in a computing sense, I guess - you can come at things many ways, and in many orders; it supports creation through discovery and play as well as it supports planned invention; it works best when many things connect rather than one monolithic script doing everything; etc?)

2 Likes
#24

Yeah, I think you’re 100% accurate here. Feels playful is a term I hear used in the education space. That’s valuable to me. I prefer playful to serious in my music tooling, but like most things YMMV (your mileage may vary).

1 Like
#25

Firstly thank you for starting this thread. I was a bit sceptical at first, but it’s fascinating.

I worry that if we start trying to remove music from our descriptions we risk ending up with overly generic statements that basically say nothing.

I ended up playing a fill in the blank game with myself.

The _______ language is designed for expression and creativity.

The _______ language is designed for musical expression and creativity.

For the first I’d pick Lisp, and actually for the second I’d pick Lisp too.

What statement has “Teletype” as the answer to fill in the blank. I say this as someone who has spent a considerable amount of time working on the language and code, it is not a good programming language. And yet, if you gave me an identical module, but with Python, or Lisp, or Haskell as the programming language none of them would work as well.

Why? What are we doing in this domain that makes it work so well? Why is the sum greater than it’s parts?

Immediacy is one thing that springs to mind.

Temporalness is another. Time is at the heart of the Teletype, even more so than music. Internal time via the metro script and delays, external time via triggers. The new features that we are discussing like EVERY and the timeline are rooted in time. Likewise patterns (and turtle) are often used in the context of time. @glia talks about events earlier in the thread.

Maybe…

The Teletype language is designed for temporal expression and creativity.

I posed the question earlier in this post, “why is the sum greater than it’s parts?”, but it’s worth asking what are the parts?

If we only had the grammatical rules of the language, just the OPs and MODs, it wouldn’t feel like a Teletype anymore, would it? Just a feature limited variation on Forth.

I might feel okay about the patterns going away (others might get their pitchforks out). I could even say goodbye to the metro script.

But the triggered scripts…? That’s where I’d have to draw the line. And if they need to be triggered, does that mean the “Teletype language” can’t exist in a vacuum, does it need the ‘external’ to exist?

3 Likes
#26

I think that music needs to be a part of any central statement of purpose for TT. Can and will be people use it for other things? Probably. But the design intent is about music.

It also feels like it needs context… it doesn’t generically express musical ideas or creative expression. It does so in the world of CV driven modular synthesis.

So including something about music and something about CV or modular seems to make sense, and will help steer this away from generic statements about creativity.

We’re trying to express the designed intent of the language, not all the possible uses of it, so being specific and exclusionary is ok IMO.

2 Likes
#27

I had an enthusiastic conversation about this yesterday. Is it really about music? The core TT language has two explicit musical commands, N and M, although the only reason M is in this context is it’s short for metronome. BPM is new. Most of core TT focuses on CV and triggers. That’s not the case for additional namespaces - TI is the most obvious example.

I’m actually a-ok with making musical creativity a first class element, but I think you can make a pretty strong argument that the real basis of TT is CV, regardless of what the V is C’ing.

1 Like
#28

I’m really happy your friend is finding TT useful for visuals (seriously, that’s way cool), but I’m in agreement with @sam and @emenel that most of us are here for the music, and that being explicit about this can be a focusing function. If I don’t know what my V is C’ing, how do I make focused/constrained decisions about how that C’ing should be done?

2 Likes
#29

Fair enough. My only real goal was to get other people to use the phrase, “what my V is C’ing.”

7 Likes
#30

That is a noble goal, and I’m glad it worked out for you.

4 Likes
#31

interesting discussion. still feels like we haven’t really captured what’s so special about it, like @sam said, perhaps because there are so many ways to use it. a couple of things that i always thought were pretty unique about teletype:

  • the teletype language allows for a more direct translation of intent to a patch

  • the teletype language can do a lot with very little, and a small change in a script can lead to a big change in a patch

what i mean by this is that teletype is the only module i can think of where you directly translate what’s in your head into a working patch. it’s super easy to think “when this trigger is received i want to output a random voltage on CV 1 and i want to step through a pattern of notes on CV 2, and then shortly after fire a trigger output” and then write just that. without teletype you’d need to think which modules you need and how to patch them. teletype makes this incredibly easy.

which also means it’s very easy to start with something and experiment with variations. even changing one variable can significantly affect a scene and such experimentation can often lead to unexpected and musical results.

as a side note, feels like we are mixing 2 things here, the syntax and the purpose of the language itself, although they are somewhat related. for the syntax i would add something like this:

  • the teletype language is consistent, logical and concise

i think it’s important that whatever new ops we introduce we do so in a systematic manner.

7 Likes