#81

for all the reasons you state, i don’t think defines should happen dynamically, by scripts as your example shows.

if there’s another screen (defines) that has a list, and each define is preceded by a special character (ie #), then this would get saved with the scene and the whole thing would remain a package. scene switching would clear/reload the define table.

4 Likes
#82

Gotcha.

I’m kinda feeling like have some new variables that can hold expressions instead of numbers might be quite a lot of fun. And it would be so so easy to code up.

They’d have to be set using a mod, as that’s how the parser works at present. But internally it’s no different that using DEL or S. I particularly like that if you can change the saved expression at runtime.

Alternative syntax

FN x: <cmd>    # save <cmd> to function slot x
FN.CALL x      # run function x, returning it's output if it has one, or 0

I also think that it’s in keeping with the language, as the usage is very similar to DEL and S too.

3 Likes
#83

This

SCL4 0 5 7 10 ARP5 0 1 2 3 4 T

looks to be a very handy equivalent of this

Pbind(\scale, [0,5,7,10], \degree, Pseq([0,1,2,3,4],inf))

Is there any chance I could get access to your fork to experiment with ARP and SCL?

#84

this is a brilliant compromise. i love the execution-- super elegant. the only downside is that the user needs to remember functions by number, but i think it may be a worthy compromise. how many functions would we allow?

4 Likes
#85

What is the conceptional difference between the FN x command and allowing 4 to 8 more scripts that are not connected to a trigger input but free to use with the SCRIPT command? They could be used for more complex operations or extended initial settings. I wonder if this would be easier to understand and to use.

Also wanted to say that II like the timeline concept very much!

2 Likes
#86

adding 8 more scripts is inelegant. it breaks the form in many ways.

  • no physical triggers
  • would require a weird keystroke hotkey for execution (ie mod+F1)
  • tons of extra paging-around in EDIT mode, short of adding more modifier hotkey jumps

the FN concept is runtime defined. so you can change what the functions do using other code. you can’t do this with more scripts.

FN is a needed and helpful shortcut for long lines. chaining SCRIPTS together is inelegant. a better solution for long multi-line scripts is the TL concept.

furthermore, FN would allow you to likely shorten your scripts, so if you did want to maximally jam the 6 lines you can do so with the semicolon.

i fell that FN and TL together address a very wide range of needs without making any ugly hacks.

ps. do people use the semicolon? it’s a seriously huge improvement by @sam

8 Likes
(Teletype) expanding scripts: length and amount
(Teletype) expanding scripts: length and amount
#87

All the time. +1 @sam

3 Likes
#88

raises hand
it’s really really helpful.

I also love the idea of FN, for that same reason. especially as I’ve been trying to work more ER ops into my PN manipulations.

1 Like
#89

Hello,
I copy / paste a request i did in an another tread. Nobody answer me :frowning:

hello, i have two request with teletype, two things i miss a lot since i used it :slightly_frowning_face:

with white whale, i would love to have a read position script, there’s actually only “cue to postion” (WW.POS) . with that, you will be able to synchronise trackers positions with white whale positions, So more CV OUT to white whale, it’s just an exemple…

and with ansible, i would love to be able to change the Edit position of LEVEL, like when you push buton 1 on the module.
actualy there’s only a read postion with LV.POS. So with that new script, you will be able to use walk instead of pushing this small button 1 on the module.

is it diifuculte to add thoes ? i don’t have any skill on coding…
thanks

3 Likes
#90

Wouldn’t FN be quite limited by the end of the line constraint?
Semicolon are indeed awesome, specially for direct assignments of variables. but often there’s not enough space for multiple commands on one line.
Don’t get me wrong, I like the design. but I also see its usefulness rather limited. Maybe that’t not so bad in tt context. Or maybe it’s just because of the name “function”.

couldn’t CALL be omitted with good conscience?

edit:
what if allow FN declaration only in Live mode, the entered commands are showed with less brightness above, and the function needed to be closed with END or so (or voided with esc)? would allow for multi-line. but then the nomenclature needed to be different for separating from PRE’s I guess. just a thought.

1 Like
#91

I would prefer to use FN definition in edit mode too.

But I could see FN be comprehensive without CALL in it. FN X: defines a function and just FN X w/o the colon performs it. A bit of an analogy to using variables or operators that can set and output values.

#92

Slightly off-topic, but this kind of functions with two different signatures that do different things depending on whether or not there are parameters (typically set/get) are a prime example of these things that seems smart when you first learn about them but can become a nightmare when you actually use them.

Explicit naming is almost always a better solution IMO. If you have to check all the context all the time, immediate code readability decreases quite a bit.

#93

Yeah, after thinking about it (and more coffee) it doesn’t make much sense to make that separation. But the end command could be an option to think about. Then again multiline would be a novice and not consistent with the other notation. That was my motivation.

#94

Lots of stuff in here, some quick comments.

  1. I use ;, it’s great.

  2. Would love to have an easy & short way of setting value ranges for PARAM and IN, but whatever you guys do, please make it consistent between TXi and TT.

  3. I am a noob reg so many things, and coding is one them. Anyway, the one thing that made me buy TT (and get into monome in the first place) was its simplicity, its non-intimidating lingo, its limits – and most importantly the tutorials on the website. In the light of 100 more TT being produced, wouldn’t it be better to update and expand on the tutorials to match v2, before adding more things to the (awesome!) TT v2?

2 Likes
#95

absolutely. the tutorials need a serious overhaul to integrate new methods into each related topic, and then add one or two additional tutorials. this will be a considerable undertaking.

also-- with the release of v2 an entirely new reference documentation system was initiated, but it remains to be published.

at this point much of TT’s development is community-driven with contributions by many different people-- and everyone will have their own particular interest and area of expertise, so priorities become a management issue. i’m responsible for the tutorials, and i’d like to get them updated just after we get a few large features implemented.

3 Likes
#96

these are both reasonable requests, i’ll get them on the list

4 Likes
#97

I wonder if in scale transposition could be a reasonable request too?

Something that transposes e.g. Kria from tt while staying in the chosen scale?

Or is it too much of a particular interest?

#98

This might sound silly but…does anybody actually use LIVE mode?

What are it’s strengths and purpose?

#99

I really like the idea of the Library/Timeline/Function List. This would be very helpful. An addendum is to perhaps add another icon in the upper right whenever a library/timeline/function is being called or accessed.

Don’t forget we still need more patterns! Lots more! I understand RAM is an issue…

#100

oh yes. it’s fundamental to dynamic manipulation on the fly, debugging, etc