#163

It raises some questions though.

EVERY X: …

What happens on change of X? Does the counter reset?
When the new value is greater than the current counter, the counter could also just continue…
EVERY.SET X or so for continuation? For new X smaller than current counter, would that trigger the command?

#164

EVERY is interesting from an implementation standpoint because it seems like it’s the first real use for dynamic allocation, as every single line of code could need its own internal tracking variable, but it would be wasteful to allocate a variable for each line in every script.

When X changes, the counter should probably modulo wrap around the new X and leave the counter offset intact.

I like it. The community likes it. @sam? @tehn?

I’m finishing up R right now. I have M ported onto a new dynamic scheduler core and I’m waiting for dev feedback before proceeding to implementing the R ops.

6 Likes
#165

Implementing this, I just realized that we could:

R 1 -10

Counts down without executing, then enters infinite repeat.

3 Likes
#166

I would tend to keep it simple and do countdowns elsewhere. Also I don’t understand the syntax of this - are we still trying to implement this?

So R 1 -10 would be equivalent to AT 1 combined with a countdown?

How about R.PRE X Y setting a countdown measure of Y for script X in case it is activated by R.ACT X 1 ?

#167

Since it has been discussed in this thread, I’d like to show support for much longer init scripts by whatever means necessary. As the owner of four Telex expanders, I have a lot of stuff to configure!

1 Like
#168

yeah now that you mention it. The expanders really make the 6 lines feel very insufficient and I have to type in a lot of stuff every time I power up the TT because they won’t fit. To get some stuff running (eg. envelopes) you need to type in a lot of stuff (eg. first set the Voltage of the output to 5v, then activate the envelope, set attack and decay time… and usually 4 lines are gone).

EDIT: though I guess this could also be solved on the TELEX code side.

1 Like
#169

would it make sense for TELEX modules to remember their settings between power cycling? ie always write changes to flash?

1 Like
#170

No, I would really hate that. :slight_smile:

#171

or implement a preset system for parameter recalling?

edit: Stateful messaging would be ugly though…

#172

I have to admit that I agree, a longer INIT script makes a lot of sense. I think that it’s exceptional because a scene can have a lot of setup code requirements.

Because it only usually runs once a scene, I can’t see a long INIT’s lack of at-a-glance visibility as being a detriment. We can abbreviate with aliases and chain with the semicolon, but that doesn’t really play in the argument’s favour due to the reduced readability. If it’s clearly marked as scrollable, I don’t see a usability argument, only a philosophical one (which is still valid).

Just my 2 cents on the matter.

#173

Longer scripts period would be better. If you make the init script longer but then limit the other scripts to 6 lines it will just cause confusion. I understand the purpose of the 6 line limit, but I have scripts which just look like:

SCENE 6
SCENE 7
SCENE 8

I’m not sure that is exactly readable at a glance anyway. How that is easier than just allowing some scrolling is nonsensical to me. I feel sometimes forced into obfuscation because of the line limit. I think maybe for 1.0 it made sense. Now, with Ansible and TXo/TXi (especially TXi) it makes a lot less sense. The character/line limit is totally OK btw, wrapping or horizontal scrolling would just be silly.

2 Likes
#175

I think that this sort of thing is a good fit for the scrollable timeline. I guess on second thought, it’s a good place for INIT-type subroutines, too.

As to the TL feature, my only hesitation with calling it F is that it’s actually a subroutine.

Maybe we should crib from BASIC and call it GOTO or GO.

#176

Maybe TL entries with t = 0 can be autiomatically executed after the default I script.

I

M 250
M.ACT 1
etc.

TL

0 X RRAND 1 12
0 PN.L 1 8
0 …
1 DO SOMETHING ELSE LATER
3 DO SOMETHING EVEN LATER
etc.

I remains as is (6 lines) TL is the new scrollable hotness.

Or maybe TL.EXEC n is possible, so you could call additional init code as needed, from within I or elsewhere.

#177

edit typo’d R instead of F all through

this is the fundamental purpose, though TL will be F.

F 0 will execute everything at line 0, as you request. i’d prefer not to have any builtin auto-execute, so if you want a long long init script just add F 0 as the last (or first, or whenever) line to init

technical sidenote. the timeline F feature needs to come after a substantial overhaul of the USB saving system. but it’s an inevitable feature, so i’d prefer to consider any additional features with the actual existence of the timeline present

#178

Whoa, I thought TL became F and AT became R?

#179

In case R and F are not distinguishable enough why not staying with TL and AT? I think Auto Trigger and Time Line are pretty good and self explanatory terms to desrcibe what is going on.

Don’t know what F means but I have a feeling that Repeat is not exactly what the AT feature does from a conceptual point of view. Of course a metronome gives repeating clicks but its main feature is that it is auto running. Repeat is more of doing something again that originally happens one time.

#180

What I have coded of the AT feature so far has been called R and uses the following syntax:

R 1 # get time of script 1 repeat interval
R 1 100 # set to 100
R.ACT 1 1 # enable repeat
R.COUNT 1 64 # stop after 64 ticks
R.COUNT 1 0 # repeat infinitely
R.COUNT 1 -8 # repeat infinitely after 8 ticks
R.RESET 1 # synchronize the timer, but not the count

Essentially, it evolves every script into a more-powerful metronome. In fact, metro runs on the new scheduler code, and I don’t see any reason not to add M.COUNT

TL is a new screen, with numbered lines that group commands into functions, hence F, but the name is as yet undecided.

4 Likes
#181

Please don’t take this as me saying it needs to be done as follows - just wanted to share my experience from the TELEX development. :slight_smile:

When I implemented similar functionality for the TXo. I simply followed the metronome pattern and put it on each TR channel. Yes, it makes longer lines, but it is super-easy to remember how to use it.

These functions support the metronomes at various speeds, pulse division, pulse multiplication, and a repeat-limited pulse using COUNT.

  • TO.TR.PULSE.DIV 1-n α pulse divider for TR output; α in # of pulses
  • TO.TR.M 1-n α time for TR.M; α in milliseconds
  • TO.TR.M.S 1-n α time for TR.M; α in seconds
  • TO.TR.M.M 1-n α time for TR.M; α in minutes
  • TO.TR.M.BPM 1-n α time for TR.M; α in Beats Per Minute
  • TO.TR.M.ACT 1-n α activates the metronome for the TR output; α (0=off; 1=on)
  • TO.TR.M.COUNT 1-n α sets the number of repeats before deactivating (0=infinity)
  • TO.TR.M.SYNC 1-n synchronizes the metronome on the device #
  • TO.TR.M.MUL 1-n α multiplies the M rate on TR output n by α; α defaults to 1 - no multiplication
  • TO.TR.WIDTH 1-n α time for TR.PULSE; α percentage of TR.M

There are examples of the DIV, COUNT, WIDTH, and MUL functions in the TXo portion of the new documentation if you are curious. (BTW: with the PULSE alias, the TO.TR.P.DIV command is a lot shorter!)

3 Likes
#182

I think the way metronomes work on the TELEX is really handy! if at all my complaint would be in it not being consistent with how things work on the TT. But maybe this is a good chance to sort that out as well :slight_smile:

#183

I see some implications here I find worth to consider.

First you might need a place (I; TL) where you can set the variables for one (each?) R. The script it self might not be a proper place to do it as it would eat up space there plus something like R.COUNT 1 -8 should not work from within script 1 itself since it is self referring.

Also you need a place (i.e. a second script) to set an R script active, especially when you want to have it reacting on external trigger inputs, which would be nice combined with the count/countdown feature.

So this might lead to bumping into the constraints of teletype much easier than now, which might lead to the expressed need again for more scripts, longer lines, longer scripts or shorter Aliases as the use of multiple TX modules already does.

I think a clear conceptional framework is needed to decide if and how these new features should be implemented. Also to keep in mind what is possible - there are annoying glitches on the screen. They do not seem to affect functionality atm but I don’t feel confident with implementing bigger features as AT and TL as long the actual firmware seems to work so hard that I can not read the screen anymore.