#424

this is an issue of the TR.TIME being shorter than the incoming clock.

TR.PULSE inverts the TR level-- so if they overlap, you’ll get something confusing.

in v2 i’m going to introduce a strict-polarity impulse-- so you know it’ll always come up then go down, instead of inverting.

instead of rebooting just do a TR.TOG command

1 Like
#425

i see.

so for now i can just increase TR.TIME to avoid the issue?

#426

you’ll want to reduce TR.TIME. or slow down your clock.

#427

hm, TR.TIME is already at 30ms. i guess i’ll just run my clock at half speed.

#428

If 120 BPM means 500ms per beat, so let’s say 250ms square wave high, then you’d need a tempo of about 1000 BPM for a 30ms gate to have a chance of tripping up things…
I’m sure I wasn’t using gates longer than 50% of tempo cycle when I encountered similar problems last week.
Not being snotty. Just trying to contribute. I did just buy a 128.

#429

do you mean “longer than the incoming clock” ?
Anyway, this bug is a real issue (the main one) for me as well.

#430

agreed. what i imagined as a “feature” became a bug due to not acknowledging the fundamental use case.

re: clock cycle vs. tr.time:

say you have a METRO script running at 100ms. if you’re using TR.PULSE you’ll want TR.TIME to be less than 100ms, so the pulses don’t overlap. like @lloydcole said, if you’re using an external sync, you’ll need to convert bpm to ms to know what the upper limit of your TR.PULSE should be.

anyway, this is one of the first planned fixes for the next revision, which is about to get started-- right after this final TT study.

1 Like
#431

What would be great, I think, in the revision would be to have the ability to not need to think in terms of ms… for the gate lengths anyway… thinking as I type here … maybe this can be done already… TR.TIME A RSH M 2 would create a perfect square wave, I think… RSH M 3 a 25% pulse width, etc. DIV M 3 - 33%, etc
It’s already been discussed how we can determine tempo from external clock, so replace M with the variable calculated.

#432

in the video above, i’m running the op-1 at 120 bpm, and the op-lab is kicking out a 1/4 beat clock, so that would be 500ms between each pulse, 250ms at 50% duty (can’t find the exact specs on the op-lab sync pulse-width).

my tr.time is set to 30ms, which should be totally safe. this leads me to think that it’s something to do with how TT handles the incoming clock pulse. when i slow it down to 60 bpm things become stable.

#433

ah, i wonder if the clock pulse is jittery? like scripts are getting multi-triggered? can you do some sort of test to see if the script is getting doubly-executed per pulse?

#434

yeah… it looks like clock pulse jitter. i watched TT advance pattern 0 in tracker mode and it would sometimes double advance, skipping an entry.

it’s odd though, this jitter only happens when the op-lab is sending clock pulses from the op-1 tape playback. when it is set to send gate pulses from the op-1 sequencer it clocks fine, even at very fast rates.

i’m thinking maybe i can get more stability if i run the op-1 at half bpm and do clock doubling in TT.

which brings me to another question: is there a more efficient way to double (or triple, quadruple, etc.) an incoming clock in TT than using multiple instances of the DEL pre?

ie:
clock is 500ms - this would double it:

TR.PULSE 1
DEL 250 : TR.PULSE 1

triple

TR.PULSE 1
DEL 167 : TR.PULSE 1
DEL 334 : TR.PULSE 1

etc.

#435

You could try using a retrigger blocking PRE to avoid the jitter. Something like…

IF GT TIME 50 : <your command>
IF GT TIME 50 : <another command>
TIME 0

Which should only execute if there’s been more than 50ms since the last event.

Clock multiplication is always a bit of a tough one as you have to assume a constant bpm. There’s a number of ideas for creating clock multiples in the ‘Code Exchange’ post. The first one is to simply measure the interval of your incoming clock then divide by 2 (RSH 1) and use that to run the METRO or directly into a DEL pre. The problem with the METRO approach is that if your clock slows down you’ll get additional triggers before the time is recalculated, and any drift can cause double triggers. You’d also need to zero the METRO to keep things in phase.

The problem with the DEL approach is that you can’t dynamically change the multiplication factor, having to change your script if you want to go from double time to quad time. Further it means you can’t use any other PREs in your command.

1 Like
#436

just tested that out and T sat locked at 0

1 Like
#437

for V2 i humbly submit a new PRE for review:

ECHO a b

a = interval between repeats in ms
b = number of repeats

1 Like
#438

Apologies! T should be TIME above. I’ve corrected the post.

1 Like
#439

thanks!
this is helping. no more rapid glitches or inverted triggers. sometimes it misses a beat, but that’s acceptable for what i’m doing right now.

1 Like
#440

Not sure if this is a problem here but afaik the oplab doesn’t really output a clock pulse?

#441

any idea if TT can power a teensy in HID mode? contemplating a custom controller.

#442

it should be able to provide a couple hundred mA.

#443

revisiting this operation: why in this context does …mod drunk 5 not set drunk back to 5, as it would if drunk 5 was on it’s own? is it merely it’s position after mod that differentiates it from ‘setting’ drunk and instead uses it as a value in the mod operation?