#302

Q is a queue of values. A short list of the most recently received numbers. It’s a short line of memory for analyzing a short stream of data, or even just delaying data a given number of steps.

You set how long the register is (how many stages of memory) with Q.N

If you send Q a value eg: Q RAND 3 it will add that to the end of the queue and move everything currently in the queue forward by one step.

If you read Q eg: CV 1 Q you will get the value at the front of the queue. This value has been effectively delayed (or ‘shifted’) by however many steps you configured in Q.N.

You can use this in a classic way by setting Q.N to 3 or 4, then sending your CV 1 output values into the Q as well as directly to an output. Then also readout the Q to the second CV output. This will create an ASR (analog shift register) where the values are delayed at a control rate, rather than a time-based rate like an audio delay.

1:
X N RAND 12 // pick a random semitone within the first octave
CV 1 X // send the note to CV 1
Q X // add the value to the queue
CV 2 Q // read the value at the front of the queue and send to CV 2

I:
Q.N 3 // initialize the queue with a length of 3

Of course you can take this much further and use it to do many other things. The Q.AVG is a powerful way to take a moving average of the most recently received values. You could for example have a totally random output on CV 1, but then have an averaged (smoothed) output on CV 2, with the amount of smoothing controlled by Q.N:

1:
X V RAND 10 // set X to a random even volt value 0 - 10V
CV 1 X // output X directly to CV1
Q X // add X to the queue
CV 2 Q.AVG // send the average of the queue to CV 2

You can then change Q.N via live mode, or some other script to set different amounts of smoothing.

3 Likes
#303

@Galapagoose Just last night I was trying to work out how to recognize an incoming tempo to set the M in relation to it.
I ended up with a similar approach (picture below) of using TIME, and resetting it to 0 within single script. I wanted to set M to a time signature slightly slower than the incoming triggers, so I am adding the 3ms to the X variable, which is being calculated on every trigger to the TIME value. This way, if the incoming trigges slow down or accelerate, my M will always re-adjust.

image.jpg1936×1936 643 KB

#304

Yeah that’s nice. I was thinking of walking through using Q.AVG to smooth out any TIME detection drift, but feel like the TIME is actually pretty solid. Nevertheless, if you want to add a little backup for a slightly drifty clock, it would be pretty easy. Something like this:

Q TIME
M Q.AVG
TIME 0

While the above won’t be synchronized with the incoming trigger pulse, it should track the overall tempo very accurately, even if there is dramatic changes in speed.

1 Like
#305

@laborcamp @Galapagoose

Ok thank you very much for all that intel :neutral_face: It will takes me forever to master all that stuff ( in a good way ). This module is far deeper than i first thought so i can’t be happier of my investment. Nice move !!

@tehn Little suggestion: why not adding all those examples to the manual ?

#306

Yes! Perfect explanation.

Care to elaborate similarly on Stacks? :flushed:

Thanks so much!

1 Like
#307

Oh yes - that’s mostly my job! The good thing is it’s pretty easy to transplant these examples into some documentation. This kind of in-depth exploration would probably be great content for Tutorials rather than the main manual (it’s already pretty long!).

#308

woh, i just made a homemade Dual Temporal Shifter, ala Synth Tech. haha.

#309

Stacks…

I’m not the best person to explain this as the whole ‘Push’ and ‘Pop’ methodology is something I’m not really used to. However, it is a very useful method for implementing quantization of events.

The essential idea is that you choose one (fast) trigger, or the internal METRO as the quantize clock which simply contains:

M:
S.ALL // executes all commands currently in the stack

Now all you need to do is setup your other scripts as per normal, except add the stack PRE. This will add the commands into the stack and they’ll wait until the next quantize tick before being fired off. This would particularly useful if you have two separate clocks that don’t have a strictly defined relationship.

eg:
1:
S : TR.PULSE A
S : CV 1 V RAND 3

These two commands will thus wait until the METRO event as above.

1 Like
#310

So what is II ES.CLOCK supposed to do exactly?

#311

cool. i’ll give that a shot.

#312

First you need to enter enter TT clock mode for ES:
II ES_MODE 1

You could put that line in the I script so it is set when you load the scene. Or you can just tab into Live Mode and type it directly.

After this you just send ES_CLOCK a number (the actual number just needs to be non-zero but doesn’t mean anything else). This event will cause ES to advance to the next event of the current pattern. It should be noted that presses & releases are separate events which preserves things like legato playing. Any recall of shapes is recalled as an event as well.

To think of it another way, it’s an event-based clock, rather than the time-based clock that ES uses internally. Thus you can change tempo dynamically, but also it requires the rhythm to set by the incoming clock.

1 Like
#313

Hallelujah!
It worked, and it’s the first time my earthsea pattern plays in sync with the rest of the case!
Epic.
:smile:

1 Like
#314

Hm, I’m really trying to wrap my head around how this should work, but what’s the deal with the number. How can I clock ES with an external clock?

#315

Just put this in your trigger input script:

II ES.CLOCK 1

#316

So:
I ES.MODE 1
1 II ES.CLOCK 1

And send a trigger to 1?

#317

That should do it!
In fact exactly what I have going.

As @Galapagoose said though: each trigger will “advance” the step, AND the end of step, so to speak. So you will see that the triggers will have to arrive at twice the speed. If that makes sense.

#318

you’ll need:
II ES.MODE 1
in your Init script.

Also, when you’re making an Init script, you’ll need to force it to execute (press Windows + I) otherwise you’ll need to reload the scene.

////

There was a question about Live Mode, and I just wanted to clarify that everything runs concurrently. If you just want to execute a command once, or check the output of a certain math function you can just tab into Live Mode and type away. Everything is executed immediately while the scripts are still running in the background.

#319

Yup: he had the “ES.MODE 1” in the I script above.

I often just paste the same command I add to I script, into LIVE mode and execute them as I am writing things.

The Window+I is definitely a useful key trick!

#320

is the physical paper manual available online somewhere? i left mine at work, and it has some additional info on it that I’d like to reference.

#321

@dudadius My teletype did not come with printed manual, but I made these cheat sheets with commands and key functions. Am not sure what you are looking for exactly, but maybe this will help. These are formatted to print nicely on standard letter paper.
p.

TT_commands_card_1.3.pdf (887.7 KB) TT_keys_card_1.2.pdf (815.3 KB)