(Teletype) Pre-2.1 Operators and Features


#142

:stuck_out_tongue_winking_eye:

I am starring at my MacBook right now and I am pretty sure that there is no backslash. And yes, It’s a german keyboard.

Ah, I just found it on the teletype keyboard - looked at the wrong backslash and those pipes seem to be arranged above each other on the key with the right backslash. So I will try to use them in future. :smiley::+1:

I always thought about Max/MSP but still hesitate to get into it, for good reason I am afraid…also I see that a lot of the things people with a lot more understanding do code in Max/MSP in the end do not always work as intended. Plus starring in a computer makes my eyes hurt…


#143

+1 for R.

+1, that syntax reads pretty well for me.


#144

Totally agree! I hope I did not state anything wildly incorrect above btw. I also was mentioning bitwise operators just to help @Leverkusen understand why some aliases use double characters (eg. &&).

Sorry, if you got the feeling I was insinuating in any way that you are stupid, please take my excuses, that was really not what I intended. Indeed the character “|” can be easily confused both with “I” (capital i) and with “l” (lowercase L), though it’s a different character.
I do use an Italian keyboard and there it’s the character that you get by pressing SHIFT + the topmost left key (see here: http://www.smartkeyboardstickers.com/images/Italian-10038-zoom.gif). The character is a bit longer and thinner than an L.
On the German keyboard it looks like you can make it using ALT+ > (see here: https://www.smartkeyboardsolutions.com/images/German_10029_zoom.gif it’s the character on the key left of the Y)… but afaik there’s a couple of variations of the German keyboard layout so it might be different on yours.


#145

So everybody, esp. @emenel and @papernoise please excuse my grumpiness! I see you are trying to help expanding my understanding of these things. And I tend to get unpatient when things have a high entry level - I should reflect this and stay more calm.

I think my main point is that I don’t want to learn how C or C+ works (even on a very basic level) to understand teletype scripts cause I have no free ressources to do so. I just find using symbols that are so unusual in the common world that I don’t have them on my computer keyboard more unintuitive then using acronyms. Meanwhile I found it (Alt + 7; Alt + < gives ≤) but it will be the same as with the different types of brackets - I cannot memorize it and will have to look it up again and again when not going by try && error seeking on the keyboard.

It’s a question of design aims I think. And therefore I think MZ X Y: is a better solution to shorten IF NOT MOD X Y: then IF ! % X Y: is.

BTW: What is the benefit of || against OR - it’s both two characters, isn’t it?

:nerd_face:


#146

I think it’s actually a valuable point of view for the people who are working on this, so I think it’s great that you have expressed your concerns about these aliases. Not that I think that they should be removed, but I agree that they should not replace the current “spelled” out versions. And yes, || indeed offers little benefit over OR.


#147

While I get that people with no programming experience might be confused by == or ! for example, for people with programming experience these are much, much easier to read/manipulate than letters. For me, || would offer a benefit over OR in the sense that it’s something that I already write almost everyday in the context of logical evaluations.

Having aliases so that people can choose whichever operator spelling suits them best (C-like or english-like) seems to be a good solution.


#148

+1 for R.

+1 for BPM.

The beauty of implementing aliases is that you don’t have to sacrifice terseness for readability. You can use either!

But it is actually so important to be able to have terseness also - each character really is a premium in these teletype scripts.

So yes, I also would love to see single character aliases such as ! implemented.


#149

so let’s just agree that the way it works right now in v2.0 is a win-win for everybody :slight_smile:


#150

I prefer words too for prefix notation. but I now try to get used to using symbols to avoid the edge cases of running out of space. crazy idea: auto-collapse when reaching end of line :face_with_hand_over_mouth:

It’s indeed cool to have the choice!


#151

I think this plays against readability, also it may be impossible to implement.


#152

I always use the words (not symbols) on teletype. I wrote TT scripts that way for over a year & it just feels natural. I dislike the ; but I did use it the other day when i needed to put 7 commands in a test script. I also find myself using SCRIPT x to chain longer scripts, but I wish I was calling a named function (so I knew what the hell it was going to do).

Regarding the whole MZ discussion, I would think of it less in terms of how MZ is implemented, and more in terms of what MZ does. When I’m abstracting C code I name my functions what they do because at that point I don’t care how it’s done.

Thus! I suggest MZ should be called something more like EVERY:
IF EVERY x y: <cmd> // at every x’th value of y, do

It’s not quite perfect (kind of implies the counter is built in) - but it gets more directly at the single use-case that I’ve seen proposed for the function. Does the MZ op have any other proposed use case?

// edit
I wonder if, instead of thinking how to make abstractions of existing ops, we look at desired functionality more directly. Perhaps we don’t need any of the above, but instead a new PRE, that internally counts triggers, and only fires every nth trigger? Is that the use-case we’re talking about?
EVERY 3: <cmd> // executes the command every 3rd time


#153

absolutely! I was just remembering times when I had to go back to free up space. and had this silly thought, not a serious request. could be quite confusing too.


#154

I think MZ X Y offers more variations to modulate as you can have X or Y running which is different from EVERY X with a modulated X. Also I like the maths of it and it’s shorter without using symbols…

Apart from that I like the approach coming from the desired functionality and EVERY X: does look elegant as a PRE.

Funny how I love the semicolon.


#155

:heart_eyes: this would be awesome – sort of along the lines of how TidalCycles operates. it’d save the cost of current hacky approaches to this, which (for me) would free a variable and a lot of line space.


#156

That’s true, but we’re already talking about reducing variations. You can already do exactly MZ (quoted from above):
IF EZ MOD X Y

It’s a restricted form of:
IF EQ a MOD X Y // where a is the equality variable we’ve reduced to 0.

The whole point of my PRE suggestion was more to probe at people’s proposed use cases. I know MZ would be more flexible, but would EVERY x: cover the majority of use cases? If there are only edge cases where the extra variable is necessary, these could be done long-form. The question is whether they are edge cases, or main use cases. Try things out long-form and see what you actually find useful.

It’s funny how this is the opposite of what I like about Teletype. I don’t want to feel like I’m writing code. I want my script to read more like a musical score than a math equation.


#157

Yes, I seem to be a bit ambiguous here - in the end I would vote for going the route you are proposing here: More of a musical score than a math equation.


#158

I like EVERY a lot, as this connects with how I often build modular patches, using clock dividers, sequencers and switches in various ways. On EVERY 8th trigger in send a trigger out, etc.

With TT I often end up doing simple math to achieve this kind of thing, so EVERY feels like a nice addition.

I was going to suggest some start of / end of pattern ideas, but haven’t thought them through, e.g. :

EOP 1 : (cmd)

SOP 1 : (cmd)

i.e. execute (cmd) at Start / End Of Pattern no. 1.


#159

yes please! That would be awesome, clock divisions are something I use a lot as well!


#160

I too very much like where this is going. Also: Every (E) would coexist well with R…


#161

This would be highly appreciated!