#4

I tried rewriting that line so that it’s true:
Everything can be translated into or expressed as voltage

2 Likes
#5

It could be said that Teletype is a tool that permits translation between the conceptual layer of music and the physical layer of modular synthesis.

As such, it establishes primitives of those layers within the internal context of its scripting language.

… I’m not sure that gets us any closer to a maxim. :upside_down_face:

6 Likes
#6

This is more about the hardware than the language though, right? @scanner_darkly has talked about ‘Ansible Satellite’ where code written on the Teletype could be loaded to Ansible and executed as a sort of headless Teletype. It doesn’t exist yet, but given his track record it’s probably only a matter of time :wink:. Here’s a post explaining it a bit more, Grid ops / integration

If Teletype code running on not-Teletype hardware exists, do we lose the constraints of the current hardware? Or is there something to the available space on the TT module that’s important beyond the actual size of the screen?

#7

It’s not a hardware constraint at all. We have discussed scrolling and wrapping, and they have been rejected by the community. Intention of this constraint is to keep scripts small and easy to understand at a glance.

In fact, I’m going to add that:

Readability and learnability are important. Everything should be understandable at a glance

5 Likes
#8

That’s a pretty high bar for anything sufficiently complex.

Come to think of it,

This is super hard to achieve with Polish Notation. What’s the idiomatic ordering of operators? Consider:

A - * + / X 9 2 7 3
A - * 7 + 2 / X 9 3

Given the fact that divide and subtract are position dependent, the more consistent ordering is the first, IMO.

Even this simple math equation illustrates that it’s pretty hard for this syntax to be readable at-a-glance.

edit: I suppose my pedantry itself violates the anti-purism maxim in a meta sense :slight_smile:

2 Likes
#9

Maxims are hard…

2 Likes
#10

Except, how often do you write in pure python? I suppose a software developer might. Then again, I suppose a software developer would be spending more time in C/++ than Python. My work always starts with importing a bunch of libraries without which I would be severely handicapped, and most of which do not adhere to the commandments, even the Google-maintained tensorflow.
My point is, absolutism is a two-faced hag.

1 Like
#11

The first sentence and second sentence are not necessarily compatible. Something can be learnable - consistent in its rules, small vocabulary and grammar - and yet still take more than a glance to understand.

A useful adjective in language design, to throw into the mix I’m not sure how, is expressive. I would not sacrifice learnability for expressiveness, but I might sacrifice legibility.

2 Likes
#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