#143

+1 for R.

+1, that syntax reads pretty well for me.

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

4 Likes
#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.

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

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

1 Like
#149

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

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

4 Likes
#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.

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

6 Likes
#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.

1 Like
#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.

1 Like
#159

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

1 Like
#160

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

#161

This would be highly appreciated!

#162

Iā€™ll add my voice to the chorus: This would be great.