#21

Looking at implementing PARAM.SCALE with the following operators:

PARAM.SCALE [X] [Y] // Compound setter
PARAM.SCALE.X       // Get / set lower bound
PARAM.SCALE.Y       // Get / set upper bound

A thought occurred: we could make a compound getter if the fallback position for TOO MANY PARAMS was to print out a list of the remaining NUMs in live mode. (edit: looks like this change could be accomplished entirely within live_mode.c!)

#22

(Not operator-related, but) I’ve just submitted a PR that implements code commenting in edit mode. Pressing ALT-Slash (/) disables the current line from executing. Pressing it again re-enables it. Commented lines are indicated by a dim font.

1 Like
#23

Does this mean that the actual teletype firmware is already changing again? I understand that my lack of knowledge is annoying to you professional coders but I find this a bit confusing and would want to know if I have to adept myself to new commands, sudden dimming fonts and not executed scripts when I press a wrong key.

:sweat:

#24

I wouldn’t worry about the firmware imminently changing. I’m just uploading changes that I’m making to the code base, it’s up to @tehn to determine the release schedule.

edit: Just to be clear, the intent of this thread is to hash out ideas for new operators (and I guess other related firmware changes). What eventually goes into a release will be determined by the administrators of the teletype codebase, who I presume is @tehn . I might recommend reading the suggestions here with a grain of salt, and as you use your teletype more, you’ll be able to consider them better in the context of the existing operators / functionality. If you see an idea you like, give it a +1, but don’t get worried if some potential new feature and its purpose and significance seem cryptic.

Part of what seeps in to this conversation are the differences in vision between people about what teletype should be, and sussing out these differences can seem like a pedantic argument, but I think everyone involved is operating in good faith, so there shouldn’t be any conflict. I, for one, am happy to take my direction from overall community support for an idea, as well as the guidance of the existing codebase contributors.

(P.S.: There’s nothing annoying about asking questions (at least to me), we were all new to this at one point!)

5 Likes
#25

I was thinking about this. In addition to or in lieu of this, How about an operator like LAST, which would return the number of milliseconds elapsed since the script was last called?

I bothered to implement this functionality. It’s pretty neat:

1: M LAST
M: TR.P 1

Tap tempo in one line.

Typing LAST on the live console shows the time since the last INIT script run.

#26

That’s too complex IMO, having settable bounds will lead to user errors. I think we just need to pick 1 way of doing it. With the fallback that you can use SCALE a b x y PARAM.

Either lower and upper:

PARAM.SCALE x y

or just upper:

PARAM.SCALE y

(Remember we can always ADD x PARAM.SCALE y if we want a lower and upper bound.

I would add an alias for it too. Maybe just PRM.S?

1 Like
#27

Do you mean 1) setting a prescaler that alters future calls to PARAM, or 2) an operator that returns a scaled PARAM?

#28

I think the AT feature would cover ratcheting capability. I’m looking for feedback on syntax of that feature here before I start work on it, as the different syntaxes will necessitate vastly different work.

Current status:

  • MSPB (milliseconds per beat): Done
  • LAST (milliseconds since a script was last run): Done
  • BREAK (stops a script’s execution, alias BRK): Done, tests okay in sane contexts
  • PARAM/IN scaling: discussing syntax
  • AT: discussing syntax

Commented line visual indicator

It occurs to me that even if we can’t use # or // in the script syntax, we can still use one of them in the visual rendering of the line. I find that it might be hard to distinguish between the current intensity levels, and so should be made more clear. I could also make the font darker, and render it as black over the selected line so that it could be seen while selected.

1 Like
#29

For fun I implemented a while loop with operator W.

:slight_smile:

2 Likes
#30

Of the code I most often write, I check if X % Y == 0. Currently, the command is:

IF EQ % X Y 0: [some sub]

This uses a whopping 13 chars and 50% of the 12 operator limit, so it seems a prime candidate for abbreviation. How about:

IF MZ X Y: [some sub]

Where MZ stands for mod zero. MZ returns true when X % Y == 0. This syntax uses 9 characters and only 4 operators.

edit: Maybe %Z?
edit2: PR submitted as MZ. Can add alias to %Z if anyone wants.

2 Likes
#31

How about a built-in counter for the M script that auto-increments?

I: M.INC 3
M:
   IF TOSS: X + X 2
   IF TOSS: X - X 1
   IF MZ M.I X: TR.P 1
#32

If anyone’s interested in trying the changes so far, I’ve integrated all the patches so far into my personal build branch, including the built teletype.zip file.

#33

Any chance you could keep an updated list of what you’ve done in the first post?

Also I’m going to need some sort of community consensus or direction from above before I can merge each op.

#34

I am happy that the whole system seems to be running stable with the new firmwares and only a few and not severe bugs might be left here and there.

Following this thread it seems as if the command palette could be doubled within a few weeks and I hope that for every single enhancement it will be tested and assured that it won’t make the system unstable again.

Generally I would prefer to keep the syntax consistent and not to have too many too specific commands or derivates from already implemented ones.

I like some of the new ideas but also I have seen modules and computer OS’s getting improved feature wise to an extend that they lost their initial usability.

Keeping the initial design framework with its boundaries intact should be a goal I think. Widening those goals with good judgement might be a goal too.

1 Like
#35

MZ or %Z, or any such reuse of those letters, is a bad idea. M is Metronome, and Z is one of the four available variables. “MZ”, or any slight variation of its components, is too similar to the established definitions of existing units. also, it could easily be mistaken for M times Z.

going back to your example:

IF EQ % X Y 0: [some sub]

…makes everything visible. all operations are clearly seen, and the variables are understood. the only thing that’s needed to remember is what order they’re in. while this:

IF MZ X Y: [some sub]

…hides what’s going on. it’s opaque to the user, not clearly laying out the actual logic/operations, and it reverses the expected order of events compared to the usual scripting flow. it also confusingly reuses existing unit names mentioned earlier.

there doesn’t need to be dense shorthand (abbreviations for abbreviations!) for every item in teletype. i think monome had the right idea when they placed well-defined line number and length limits.

1 Like
#36

Tbh. more operators feel like you’re starting to succumb to feature creep :slight_smile:
on the other hand, there’s one thing that might make using the current selection of operators more effective: overcoming the limit on number of lines and number of characters per line.
I do think that putting a limit to that is needed and even creatively interesting, but with the amount of stuff you can do now with the TT, the 6 lines per script start to feel a bit tight. Also while chaining ops is partially solving that, often you can’t fit more then one in a line anyway.
Another thing worth considering before adding more operators: make the trackes 8 tracks instead of 4 and maybe bumping the length up to 128.

#37

I mean don’t alter future calls.

#38

To be fair, EZ X is also a special case. It’s not a common operator and is also already covered more readable by EQ X 0. Also, most OP have to be initially looked up in the docs.

But I agree the name could be better. Maybe RZ as in remainder zero?

It seems there are two different TT user groups. Those with and those without previous coding experience. While I understand that some operators are hard to grasp for non-coders, I believe that’s already the case with the initial command set. In the end, TT is a scripting ecosystem. And since screen size is spare, I’m in favour of such optimizations, if their not too abstruse. In fact, this specific one would be very useful when counting, to do something each Y step.

What about separating/hiding advanced OPs in an Advanced Section in the docs?

1 Like
#39

As long as the chance of making a typo is reduced by making sure operators do not have too similar names, and as long as they add useful functionalities (and given the space constraints of something like Teletype, gaining half a line is valuable and useful), additional operators seem like a good thing to me.

The way I see it (as someone who still hasn’t got the module :slight_smile: ), coding with/for Teletype means both creating operators for high level things that I’m used to doing in C++ for example but would be convoluted/impossible on the device and then using all the operators in Teletype scripts.

Naming should remain as intuitive as possible though. A strength of languages like C/C++/etc. is that many keywords are easy to understand, which makes reading code much easier even when you have decades of experience (i.e. if, then, else, switch, const, nullptr, break, continue, etc.).

1 Like
#41

Existing ops: 324
Proposed ops: 6 maybe?

Seems hyperbolic…

Are you opposed to abbreviated aliases of existing ops, e.g.: + for ADD?

What about EZ / NZ? MOD starts with M. I don’t get this concern because the syntax is whitespace tokenized.

There are 8 general purpose variables, A-D, X-Z, and T. Although there may be idiomatic uses of some of them, they’re all in fact general purpose. Again, whitespace tokenization means that MZ cannot be M times Z. I don’t think this is in any way confusing.

ER is pretty opaque to the user, should we force users to reimplement the algorithm because it could be expressed explicitly? (Also we should scrap EZ et. al. by this metric).

+1, this is my driving force.

+1, we can’t make the language completely intuitive AND powerful.

1 Like