(Teletype) Pre-2.1 Operators and Features

[sliderule]

the namespace is pretty limited

Thinking about this, I have to disagree because we are tokenizing with whitespace. If you had a truly unique namespace, it would still be pretty big. I think you could make a compelling case for expansive functionality using a language that only required tokens between numbers.

IFMZY4:TR.PLIM+Y-RAND1,1,4;XABSO

(32 characters, 16 operators)

I’m not saying that the current operator names could work, but I bet I could get a set that was reasonably close in name and identical in idiom and function to teletype script and retain human readability.

(Note: this fictional language is an illustrative device and does not represent my desire for teletype syntax.)

Adding whitespace tokenization vastly increases the universe of the identifiers in the syntax, so I don’t think this is really at issue.

---

That said, I certainly share the concerns of the group: the syntax should be unconfusing, the operators universally useful, and scripts easy-to-read.

That I write the code gives me undue, if unintended, influence in the design and naming process of the code I write. I will always hold that of the code that I may submit, any of it may be discarded or modified to meet the needs of the community as it sees fit. My goal is to enrich the community, and I hope that my work is to that end, but I don’t lament failure.

I apologize if I have seemed imposing, which is certainly not my intent. Now is as good a time as any to inform you all that I am autistic, and as such have difficulties communicating and “behaving normally”. I’m working on it. Please send me a message and say hi if you’d like to introduce yourself.

I’ll shut up now and get back to the actual work at hand.

edit: Original post updated to include current status.

[scanner_darkly]

no apologies needed! if was just the rate of introducing new ops that seemed alarming and i hope i didn’t come across as simply rejecting all your suggestions - there are several ops that i’d love to see, and for the rest i tried to understand the use case behind it - teletype is flexible enough to allow for many different styles, it’s always educating to see a different approach (i never thought of using all of the scenes for one composition - would love to see that if you have examples posted anywhere!).

teletype is quite possibly the most unique module in its approach, and i would love to see more people with no coding background try it. that’s really my main worry about making it into something that people might consider too difficult to use.

[oscillateur]

Btw, I had a quick look at the pull requests on Github and the ones for new operators (or rather their changes tab) are a good documentation for “how to make an operator”.

[Leverkusen]

Funny, because I’m sure most people would call 1 + 2 x 7 “normal” and 1 ADD 2 MUL 7 “strange”. The only thing different about TT syntax is that it’s prefix notation, whereas most of us learned infix notation, and some learned postfix.

I can understand being confused by the usefulness of the Modulo function, however. How often do you need to know the remainder of a division versus the quotient in the real world? You’re right that this function is much more familiar to a programmer because it’s very common to calculate offsets.

Short answer, MOD (%) (Modulo) is the remainder. It’s a handy thing to know, and in the context of rhythmic division, it’s handy to know when it’s zero.

It seems that we have different ways of handling pattern recognition. So let me explain this again:

For me 1 + 2 x 7 looks as normal as 1 ADD 2 MUL 7 does. It is just swapping the common symbols against two intuitive names for them and I hardly notice any difference between both expressions. There is nothing strange in it for me.

What makes a big difference to me is indeed the prefix notation. This is what is breaking/changing the pattern, not if I use “+”, “ADD” or “plus” in the usual places.

Using an operator like ADD or MUL now generates a coding framework and leads my perception into this direction. When I now read X ADD Y Z I immediately know this means X shall be the sum of Y and Z.

Notating the very same thing with symbols as in X + Y Z does not generate this perceptual framework. At first it looks like a browser generated password suggestion to me, then I have to abstain from automatically adding X and Y.

Regarding the modulo function - I know what it does and I use it regularly. What I meant is that all the above is getting more difficult for me when symbols are used which already have a common meaning. % A 4 does not only look like a random string to me it also has nothing to do with percentage calculation. It’s the same with “==” btw…

On the other side, of course I often bump against the end of a line and would wish for more space or an additional line. And I can see that condensing the command set/syntax opens up more opportunities (I am very happy that we got rid of the empty space before a colon for example) - I am just advocating to do this cautiously to keep it accessible for everyone.

[sakul]

CHAOS made me realise how subjective individual needs can be. Is it supposed to take the formula as user input? If not, is it just a more repetitive RAND? (“TM” anyone?)
Im totally aware this was just an arbitrary example for reference. But to me personally, the MZ proposal (still think RZ could be a good alternative) would be much more useful in the command set. Which leads me to the question:

How can we determine what the community wants? Should we make polls for each proposal (with tehn as last instance)? Or is that too easy and prone to distortion and people should write down their opinions? Still I think there could be a silent majority that just trusts tehn and has no interest in crawling through threads like this. Not an easy undertaking (sam probably knows that best so far).

However, this discussion made me realise how excited I am about TT, and thankful to tehn for bringing it into our lives!

So how could we make it more attractive to new users? Making it multi modal? Say plug in usb midi -> configurable midi/cv (with one cv in/knob). Or an oscilloscope mode? Monome/Arc apps? Games? Of course I don’t want to bloat the firmware, but it could be a cool (and fun) way of gaining some attention, as separate firmware. A bit off topic sorry.

Just thinking out loud here.

[ether]

Some random thoughts here.

We have LIVE, EDIT and TRACKER modes already (I’ll ignore SCENE modes for simplicity).

How about a SCRIPT (or EXTENSION) mode, which is really just one long, scrollable page (up to the limits of the module) that can be used to write callable functions?

e.g. (Imagine something like this all on one mode/page)

FUNCTION MYRANDOM
RETURN RRAND 1 12
END FUNCTION

FUNCTION WHATEVER
DO SOMETHING INTERESTING
END FUNCTION

etc.

I can then call MYRANDOM and WHATEVER from other scripts.

This would be the one and only place that scrips could be longer than a screenful and scrollable.

People could write / share extension scripts as they decide they want to in order to extend the language, introduce aliases, etc. Or just completely ignore the whole thing to keep it simple.

I’ve only had one coffee, so this may be a bad idea, but on first blush it feels there’s something useful here.

[oscillateur]

The problem here would re-usability between scenes. You would have to retype everything every time, basically.

As it is, individual scripts already kind of work like functions with no parameters, if I’m not mistaken.

[ether]

I’m imaging just one extra special script per scene, that is saved with the scene, that supports scrolling and some form of function syntax.

Alternatively it could be a “global script” or even “global scene” that other scripts could share.

[papernoise]

How about a SCRIPT (or EXTENSION) mode, which is really just one long, scrollable page (up to the limits of the module) that can be used to write callable functions?

why not just make the script edit mode so that the pages can scroll? Wouldn’t that serve the same purpose but keep the UI complexity lower?

[ether]

I tend to agree with @tehn that avoiding scrolling of scripts is a good thing, keeping them glanceable.

So I was thinking of options to extend things without changing existing behaviour.

[tehn]

Alternatively it could be a “global script” or even “global scene” that other scripts could share.

this is similar to my “timeline” proposal way long ago: Teletype v2 proposals

it could be used as a function-calling system for making more complicated scripts (may need a few modifications to the proposal).

i still like the idea, but it’s an undertaking. i’m ok with this section being the one part that scrolls. plus it has a very different fundamental use-case, which sets the visual component apart from the other screens.

[sliderule]

As someone who’s never used csound, can someone flesh out this timeline concept to me? It seems that the first column is an interval and that there’s an auto-incrementing index, and the condition for each line’s execution is its first column’s equality with the index?

[sliderule]

I am just advocating to do this cautiously to keep it accessible for everyone.

I hear you. Thanks for your input!

CHAOS made me realise how subjective individual needs can be. Is it supposed to take the formula as user input? If not, is it just a more repetitive RAND?

It would have a built-in formula (or a few) and some parameters, and it doesn’t necessarily repeat. Check out the logistic equation for an example.

How can we determine what the community wants?

+1

[scanner_darkly]

since a lot of this is driven by length limitations perhaps that’s where we should start? i also like being able to see the whole script at once, so how about just extending the number of scripts to 16? (or some other number).

this would work well if we also introduced a way to pass parameters into scripts. this is already doable in a way since all variables are global but having proper parameters would make them behave more like proper functions. we could have special variable names P1, P2 etc (maybe a different letter to avoid confusion with patterns) and then if you call a script like this: SCRIPT 1 123 456 in the script P1 would have the value of 123 and P2 would have the value of 456. if a parameter was not passed it can default to 0.

also what if we introduced a way to define aliases dynamically, with the scripts themselves. this should probably be limited to expressions only, so you couldn’t define an alias for something like L 1 4: - this wouldn’t be feasible for several reasons, but if we limit it to expressions it means we could evaluate an alias for correctness right when it’s defined. such expressions would be calculated whenever the alias is used. as an example: FI: SUB MUL I 2 1 defines an alias FI which is I*2-1 which then can be used like this: L 1 4: CV 1 N FI. basically, these aliases would serve as inline functions. this could partially address not having MZ as you could just define an alias MZ: EZ MOD A B (assuming it’s MOD A B you need).

[trickyflemming]

this is similar to my “timeline” proposal way long ago: Teletype v2 proposals

it could be used as a function-calling system for making more complicated scripts (may need a few modifications to the proposal).

i still like the idea, but it’s an undertaking. i’m ok with this section being the one part that scrolls. plus it has a very different fundamental use-case, which sets the visual component apart from the other screens.

I had an idea where this could be simplified.

Currently, we have SCRIPT x, which calls x Script on the current Scene. It would be cool to have something like SCRIPT y x as well, which calls x Script from y Scene. That way, you could keep Scenes of commonly used scripts without having to create yet another mode.

However, this idea assumes things about Teletype RAM that I am gleefully ignorant of

[sliderule]

However, this idea assumes things about Teletype RAM that I am gleefully ignorant of

I was, too (although not gleefully), and it has way more than we’re using. I can’t imagine this thing becoming RAM-limited with the current scope.

It’s more of a design question of how many scripts there should be.

[Pampalini]

I have a soft spot for the high level sequencing commands in SuperCollider’s pattern library. How would the community feel about something akin to

PSEQ num_0,.. num_k

where the k numbers are limited by the line length, and there is no explicit time interval. Every time the command executes, it spits out the next num_j in line?

I imagine using this for instance like this:

X PSEQ 0 3 5 7
If TOSS: Y ADD X PSEQ 12,5,7
ELSE: Y ADD X PSEQ 11 13 17

Or other ways for creative pattern composition.

I realize this can already be done using the tracker and a combination of commands. The point of this would be the convenience of having high level commands available (same way that CHAOS can be done with a combo of commands, but having it as an OP promotes its usage), and immediate visual feedback on the pattern values, instead of going back and forth between the tracker and script modes.

I would offer to do it myself. But I’m not well versed in C.

[tehn]

aliases are something i’ve considered. it’d need a special character.

ie

DEF #DEC X SUB X 1

and then #DEC could be used anywhere instead of X SUB X 1

figuring out a UI for definition and listing is a whole different issue. ie, the INIT script would just get clogged with defines. so it’d need to go somewhere else. but the # is important to provide an entire namespace, and call out to the user that the alias is a different/weird/other thing.

However, this idea assumes things about Teletype RAM that I am gleefully ignorant of

absolutely not enough RAM. it’d require grabbing that data from flash, which may or may not be a reasonable request at fast runtimes

[bpcmusic]

First, I really love the Teletype as it is. For me, it is the most beautifully elegant thing that @tehn has designed so far. Both its capabilities and limitations are extremely inspiring. The device and its integrated language extend each other’s metaphors beautifully.

I also think that @sam has done a wonderful job shepherding that design philosophy in the 2.0 enhancements. When I imagine useful extensions for the thing, I challenge myself to be as mindful of those ideas as they have been. “To make everything as simple as possible, but no simpler.” (Not necessarily an Einstein quote: https://quoteinvestigator.com/2011/05/13/einstein-simple/.)

---

Here is where my head has been at with this stuff, if you are interested.

1. Love the idea of passing parameters to scripts that @scanner_darkly - almost did it a while back on a lark and restrained myself to keep focus on the TELEX. It feels natural and could be really helpful.

2. Really like @tehn’s timeline proposal as well. I think of it like an event view in a sequencer - give an event time (in MS or triggers or beats or …) and a command / script to run at that moment. With the ability to pass values to scripts (from #1 above), this would get even more powerful. (This would be appropriate to scroll in the context of the Teletype, I think, as its metaphor seems to invite it.)

3. I like the runtime aliases / scriptlets ideas above as well (with parameter passing). This would clear up one of the problems that I’ve caused for myself and others by making some of the TELEX commands on the long side for intelligibility. If I want to use one a lot (or in a loop where I’m running out of space) - boom, make a runtime alias.

4. I’ve gone back and forth on this, but I don’t think scripts should wrap lines and I don’t think that they should extend beyond the screen. This limitation is one of the things that “just works” in the design and actually inspires creativity. I don’t think we should mess with it as it will add confusion when visually parsing scripts when commands are wrapping and/or falling off the view.

5. Memory aside (not sure where our limits are), I think having some more available scripts would be nice - but I feel like they should extend the metaphor of the device. Right now, scripts map to trigger inputs … they relate to a physical thing. There is something magic about the way that works in your brain when you are interacting with the instrument. The best way I can think of to add more scripts would be to add “shadow” or “alternate” scripts that sit under each of the individual 8. This way - you still would only be paginating through 8 scripts in general use. The complexity of the additional scripts would be out of the general path of usage for a novice user - or advanced user doing something light. You could cycle into a script’s alternate using another set of keys. You could call the alternate script using a designator - something like SCRIPT 1A - though I loathe using a variable designator there that could be visually confused. You could even swap alternates in for the primary script if you want - creating new trigger behaviors that can be programmatically introduced into the patch. (INIT could also have alternates that you could “chain” in at script startup to handle additional commands/aliases/etc.)

---

Anyway - still lots to think about - but, that is where my brain is at the moment.

[sliderule]

absolutely not enough RAM. it’d require grabbing that data from flash, which may or may not be a reasonable request at fast runtimes

A selective script load combined with a prescan at scene load shouldn’t be too bad, though, should it?

I’m seriously thinking about writing a Debug / Profile screen to assist with development questions like this.