It’s a bit fiddly but you could use another variable that is, say, ten times bigger. Divide that down and use that instead. For example:

M:

TR.P 1
IF < A 500: A 10000
M / A 10
A / A 16

(I’m not 100% sure this will work quite the same way as the original because I’ve skipped one of the conditionals - and I’m not at the Teletype just now.)

The trick here is to divide a number that’s ten times bigger by 16 instead of 1.6. Then you scale it back down when actually assigning to the metronome.

2 Likes

yes that does the trick!!
thank you!!
I tried this (without using another variable):

M:
TR.P 1
IF < M 50: M 1000; BREAK
ELSE: M MUL M 10; M / M 16
ELSE: M / M 10

:blush:

1 Like

That’s elegant! Although it’s worth noting that the two solutions might have slightly different timings because in the one using just M, the rounding down that’s introduced by dividing by ten effects the timing next time the metronome fires. It might be interesting to see if you can hear the difference for certain values of the slowing down parameter.

1 Like

I don’t think you need to start those last two lines with ELSE since your IF line ends with a BREAK.

1 Like

Hi everyone! Making another attempt at getting the TT Under my control. I have been thinking about a certain issue and haven’t really been able to work my way around it;

Say I am working with the internal metronome; I am trying to sequence my Mangrove (or any other VCO/VCA combo). I want a section in which notes are fired, not at periods of beats, but certain intervals of time.

I wanted to set the script up using patterns.

P 0; notes for the V/oct of the mangrove
P 1; different milliseconds for length between TR.P

P 3 and P 4 are for some CV stuff elsewhere that I have working fine.

Now, how in the heck would I be able to trigger the TR.P to happen at certain specific intervals like that pattern? I can’t figure out a way to trigger a script or place this in the metro without basically either firing the TR.P or resetting the time to a new one without maybe having triggered in the first place

Any thoughts?

I’m not sure I entirely follow, but did you look at DEL and $?

So if I understand it, you have the metro running, but would like to fire triggers between M cycles. DEL would delay the rest of the line by some milliseconds. The thing is however that DEL is a ‘pre’ and you can only have one pre per line in tt. Hence I suggest you do this from M

DEL 123: $ 8

Which would run script 8 (with all the logic and pres you want) 123 ms after the metro tick.

Not sure if this is at all helpful :thinking:

Does the DEL end up stacking the command? My concern is, what happens on the next metro tick? What if I wish to DEL longer than what my metro is? Say I am working at M 125 and I want a note to trigger in 400ms; would I still use

DEL 400; $ 8

Basically, I want to wait specific milliseconds between TR.P, instead of metro ticks.

Hey @kasselvania – was reading through this thread after we chatted about this last night. Check out this earlier post from @robbbiecloset and the replies to it. Think it’s similar to what you’re trying to do:

M is whole note length
X is repeats (must be 1 or greater)
Y is division of whole note (e.g. Y = 16 for 16th note repeats)

In your M script:
DEL.R X / M Y: $ 8

If you want to constrain your repeats such that they never run longer than each metro tick, prepend DEL.CLR to your M script.

If you want note patterns that are not straight tuples, you might try DEL.B from my latest experimental firmware in the v3.2+ beta thread. It is not merged into the main firmware yet because my CPU exploded :slight_smile:

nb: your maximum number of “waiting” delayed events is 16 in the main firmware. It may be increased to 32 or 64 in the near future. If you’d like finer control over your patterns, increase M rate to half or quarter note speed and change your note divisors equivalently.

1 Like

Ah, i think this could get me where I’m going.

I think what I was trying to is maybe not as useful as I would’ve though which is to have the option to time puleses based on arbitrary time, not multiplications of a metro clock tick.
So, instead of waiting 10 clock ticks On a metro that is 125, I would instead just wait a full 1000 millliseconds before the next pulse. Then have these millisecond value held in a pattern.

I’m guessing that would work best with the DEL if I wasn’t functioning on a metro? I have now begun to even confuse myself.

You can use arbitrary number of milliseconds in all the DEL functions. In my example above you would just use Y = milliseconds instead of Y = divisions and then replace / M Y with just Y.

1 Like

Holy crap. Awesome. Thank you.

I’m not sure why I got so furiously hung up on this, but it would allow me to both have quantized and non-quantized values which just seemed like how I wanted something to go. And when I can’t figure out what I have in my head, all output stops till I figure it out. Oof.

1 Like

No problem. It’s a ton of fun to set up “shorthand” for rhythmic outputs!

Couple more esoteric caveats on the DEL OPs:

  • There is ~10 mS of jitter on the execution of delayed commands.
  • If you delay a TR.P, then TR.TIME needs to be at least 11 mS or your trigger may never fire (presumably because of the above).
1 Like

My concern about these is that with a Metro running faster than the desired wait length between notes, that this kind of DEL trigger would just be re-fired over and over, never giving me the wait value I had wanted. I will try this out today for something I assume will sound bonkers and terrible just as a test of arbitrary sequencing times!

:smiley:

:bulb:
There’s no OP for checking whether there are delayed events waiting, but it should be easy to make one! Then you could just hold fire on new events depending on how full your delay queue is.

If you need advanced flow control, you could use a combination of the stack and delay OPs…

1 Like

Let’s be fair, I’m so far away from needing advanced ops. I have not yet really been able to find a way to truly tame the TT but I’m trying. Some things I’ve done fall under the general idea of meta sequencing my effects and certain parameters of my rack, so I can automate and explore exact movements of my tools. But I’ve wanted to look more at this semi randomized automaton that I’ve seen people create, based upon my procurement of a ER-301. The ability to mangle, re-synthesize and remix incoming audio with the TT feels like I could create semi automated and yet fully controlled Octatrack style manipulations of audio buffers.

But the first step is just seeing if I can generate a melody and rhythm in ways that satisfy me. Baby steps.

1 Like

if i understand correctly, you could just change the metro rate on each step:

#M
M PN 1 X
M.RESET
TR.P 1

assuming X is the current step. you have to use M.RESET in order for this to work properly.
of course, it’s also fun to play with the various DEL ops!

1 Like

This would then have a global effect, yeah? I was hoping for this to be generally set to just one portion of my full patch, but this would be such a cool idea for tempo shifts on a global scale!

yeah, if you want different scripts to run on different tempos then you should use a faster metro rate and divide or use DEL ops.

1 Like

is there a comprehensive guide to the tracker? like how i work out what notes i want to put it in a particular key? how i load a new track?

1 Like