#41

there’s not a good way to do what you’re saying right now without using the metro script, or by having a script trigger another script externally via a cable. inter-script triggering may be added in a future version.

this is correct-- live display of values isn’t implemented, but it’s also on the future-feature-possible list.

i noticed this for the first time yesterday as well. it has to do with noise on the potentiometer. try twisting the pot position slightly if there’s a jump. i’ll be able to filter this better for the next firmware update. i’ll add an issue now.

great patch! thanks for posting.

#42

If you’re wanting to do a small number of repetitions you could do this with a series of delayed commands:

1
TR.PULSE A
DEL 100 : TR.PULSE A
DEL 200 : TR.PULSE A
DEL 450 : TR.PULSE A
etc

Obviously this only works for up to 6 events, but it might get you through a situation where you just want to create a short burst of triggers or some such thing.

1 Like
#43

Just to add to the discussion of looping scripts.

I think it would be useful to have the ability to set the “max” value for the self incrementing variable “O”… this would allow for creating a one line command that would effectively have a loop quality.

#44

this is a good idea. though does WRAP work for your needs? ie:

CV 1 N WRAP 0 7 O

this would be a repeating 8 semitone climb. of course, if we added O.MAX we’d probably want O.MIN and O.WRAP yeah?

1 Like
#45

I used something very similar to this just recently, but having an O.MAX, O.MIN and O.WRAP would be useful for me.

I might be in the minority in this respect, but I like to save script/line space by entering certain settings in live mode after a scene is initialized.

#46

Is it possible to have a trigger input act as a gate input ?
let’s say i want script 1 make a drum roll (a looping pulse) when input is high, how would you do that ?

#47

i use MOD O b for this.

#48

I think there is no way for a script to know what the status (high / low ) of a trigger input is, they can only be triggered by the trigger associated with them. So you could try various work arounds with the metro script or one script enabling another script through an IF / variable but I don’t think you can achieve the exact action you have described.

I’ve been playing around with pre’s and discovered that you can’t have a pre in front of a pre without crashing he unit. Might not be news to most users but was trying to use combination of delay times for commands - something like:

IF x 0 : DEL 600 : TR.PULSE 2

Really enjoying learning the ropes!

#49

in the design stage i considered both features:

  • script triggers on rising as well as falling edge
  • read-variables for current input states

however, considering the existing scope of TT as is, i felt like we were piling on too much. i still feel that more scripts for falling edge would be too much. but i think adding input level reading would be ok. it definitely creates the possibility for thinking about inputs as gates rather than triggers. is this interesting to many people?

2 Likes
#50

useless to say that i am really interested !

#51

i am wondering if the 4 variables X,Y,Z and T are enough. Let me illustrate with the problem i am encountering right now.
The scene creates a random four note melody at each trigger in both 7 and 8.

1 :
TR.TIME A 5
TR.PULSE A
P.N 0
CV 1 N P.NEXT

7 :
P.N 0
P.L 4
DEL 2 : P 0 X
DEL 2 : P 1 Y
DEL 2 : P 2 Z
DEL 2 : P 3 T

8 :
X RRAND 40 64
Y RRAND 40 64
Z RRAND 40 64
T RRAND 40 64

Then i would like to be able to change the min/max notes (replace 40 64) but i’ve got no variable left.

#52

i think they are enough. when you start getting into many-many variable territory you can use a pattern for storage. ie, PN 3 0 instead of X, PN 3 1 instead of Y etc. here you’d be using pattern 3 for variable storage-- so you’d have a ton of “memory” space.

also you can overwrite A-D. then just use TR 1 instead of TR A etc. since A-D are just mapped 1-4 at startup.

1 Like
#53

I think the number of variables is just about right, especially with re-using the A-D (which I do regularly).

I was thinking about it though, and it seems that there are not too many letters in the alfabet left! :smile: most everything is used already for other purposes. I suppose one could maybe do double letters as variable names IF that were necessary? Like AA BB etc.

I was thinking about it, because I did find myself couple of times in situation where I was running out of variables. There are script elements that become radically streamlined when variables are used. And sometimes using a variable is the only way to fit the command within the limit of the line. So, what I mean is that there are situations where I find myself using variables not because I need a variable for programmatic reasons, but rather for logistical solutions. And when I do that: I tend to reach the limit.

Using PN a b c for getting and setting values in a list (pattern) is a good work around, but only in some situations. In fact I remember using this in conjunction with some math commands and TT was getting confused, as a result of which, it was setting values in the program instead of getting them… or something like that. For example:

ADD PN 1 5 8

Which appears to be correct syntax, would set a value in the pattern instead of performing the addition. (If memory serves me right. And I can’t remember if changing the order [ ADD 8 PN 1 5 ] solved the problem.)

#54

another vote for having variables for current input states, i think it would be really useful and should hardly require any computational power.

#55

Being able to read input states would be fantastic!

Would it be like a PRE?

HIGH :

I suppose if it were a PRE there could be:

RISE : 
FALL :

?

#56

i’d rather have as a regular variable so that you could use it with other PREs. something like I1…I4 perhaps?

to use it as a PRE you would just do IF I1 :

#57

I see what you mean.
The PRE implementation would be confined to the given script.
Your solution as a set of kind of “global” variables does add an interseting set of logic-like possibilities… where you can script conditions in one script that are reliant on whether gates on other inputs are high etc.

Except I would maybe suggest H1…H4 or G1…G4 naming convention rather than the I … as there are already III… involved (the I variable, the II scripts etc.)

#58

this is a known bug, it’s on the git issues list. i’ll get it fixed!

yes we’re running out of simple naming conventions. i’m up for suggestions.

#59

Variable naming conventions that would make it possible to just (potentially) use the whole alphabet:

AA
BB
CC
…

or adding a “V” in front:

V.A
V.B
V.C
…

?

#60

wonderful. Patterns. Yeah.