#1

I was working on a scheme for ratcheting sequences and found that the DEL pre behaves in a way I wouldn’t expect. In the first column of the pattern screen, each step is a value 0-4. 0 is a rest, 1 is a regular note and and the values greater than 1 are the number of divisions for the ratcheting. The main clock for the voice hits this script:

P.N 0; A P.NEXT
IF EZ A: BREAK
B DIV LAST THIS A
L 0 A: SCRIPT 3

Script 3:

DEL MUL B I: SCRIPT 4

Script 4 is where voltages are set and triggers are pulsed. I only ever get the first trigger with this method. I did a test where I made a pattern of static delay times so that the first note had a much longer delay than the rest and was able to confirm that only the first DEL command gets executed. The rest are lost?

I came up with a workaround where the first script changes to:

P.N 0; A P.NEXT
IF EZ A: BREAK
M DIV LAST THIS A
L 0 A: SCRIPT 3
S.POP

And Script 3 becomes:

S: SCRIPT 4

and M:

S.POP

This works but it ties up the M script and makes it less flexible. Maybe I want to use probability in Script 3 to possibly skip some ratchet divisions?

Wondering if I’m missing something in my original solution or if something about the way DEL statements are evaluated is causing it not to work.

1 Like
> teletype : code exchange
#2

I wonder if the problem could lie in L 0 A: SCRIPT 3

I think it just initiates SCRIPT 3 multiple times at once - as if there were A lines of SCRIPT 3 - and does not account the delay happening in SCRIPT 3 itself.

By the way what is THIS and LAST? I had a short search through the tt pdf and could not find it - what is DIV LAST THIS A supposed to do?

EDIT: ah, I found LAST and THIS in 2.1 now and understan your script a bit better. Still wonder if L is too fast for executing SCRIPT 3 before DEL is calculated as there is no confirmation call back from script 3 to the loop function.

#3

The problem is that I is now local to the script. Try:

L 0 A: C I; SCRIPT 3

Then in script 3,

DEL MUL B C: SCRIPT 4

Also, be aware that THIS was retired in favour of SCRIPT being a getter for the current script number.

2 Likes
#4

Ah… I will try this when I’m back home later. I guess I had the impression that I had a global scope even though it is a special variable that is used with the L pre. This is not the case then?

#5

That’s correct. I really only makes sense in the post-command of L and in subsequent lines in that script.

I’ll have to check @tehn’s posts on this to see if there was ever intent to keep around a ‘global last I value’ in the I variable getter outside of these contexts.

#6

Has there ever been any discussion of being able to include another pre-command in a post-command? it would be cool to be able to push things onto the stack or use delays while iterating through a loop.

1 Like
#7

I am 100% certain that that will be a no-go with the current syntax goals. 3.0 will include the Timeline feature that will effectively allow you to nest PREs, however.