When Modulo is Modu-NO

I have a long counter on the Metronome page, then I’m using different Modulos to count variations against that.

Intermittently, one of the counters (usually one of the same two) will fall out of sync with the others. For the life of me, I can’t figure out how to get everyone back together unless I reboot the Teletype. Settting my main variable/counter to zero doesn’t do it. Even INIT and reloading the Scene doesn’t do it!


A. what could be causing the counting to come unglued?

B. shouldn’t there be a way to reset all the modulo activity without rebooting?

Here’s the Scene if you want to take a peek. It’s Scripts 3 and 4 that typically fall out of line.

tt16s.txt (1.8 KB)

A few comments on the intent of the script wouldn’t go astray (I’m reading the script and haven’t had a chance to try to run it; actually can’t since I don’t have the ER-301). Which variables are the counters? T & B?

T is the main counter. I came up with the number from the fact that I mainly have 12 bar and 21 bar phrases. So found a common number and then multiplied that by 16 (16 pulses per bar in my sync setup).

Tr.P 4 pulses a reset for external gear. Tr.P 3 is pulsing the 16ths for external.

Script one fires every beat. And in turn fires 2-6. $ 7 gets fired every 2 bars (I think for the Kria…it was running 8th note divisions). $ 2-6 are all triggering different sample lanes in the 301. Kit, Bass, OB pad, and modular arp, and lastly an ambient effect pad. The Grid/ops fader for each looks up the bar length of each selection stored in the Tracker page, then uses that to create a counter that divides it up so that the new counter on each script is counting once a bar and looping at the correct length. That part was kinda tricky!

Script 7 does a similar calculation for the Kria. It is selecting from 5 3 bar/pattern sequences. Timing values are a little different due to 8th notes there.

The other grid/ops G.REC stuff is just lighting and dimming the fader array to help with navigating the sections.

Here’s what it sounds like:


Does the behaviour persist if you slow the metronome down? Given that you run 2-6 every time, can you collapse them to fewer scripts, and does that change anything?

Not helping with the modulo weirdness… but you also could use/try EVERY X as substitute for IF EZ % T X

1 Like

My hypothesis is that this has less to do with modulo (which is just simple maths), but more to do with the timing and possible latency of communication over the I2C connection to the ER-301.

1 Like

I’ve tried the Every in the past and I didn’t quite wrap (no pun intended) my head around the Sync command…it was getting things to agree on where ‘1’ is like I expected it to…but I’ll revisit that in the future.

@GoneCaving I would think that it does have something to do with i2C as well…BUT…it seems like more of a bug, than a timing issue. In that once it (and I don’t even know what ‘it’ is, really) gets stuck, only a reboot resets the timing/counter operation.

from a quick glance nothing stands out.

when you say one of the counters falls out of sync, can you explain what do you mean by “counter” in this context and what happens exactly?

Monsieur Darkly,

So each Script is triggering a sample of different bar lengths. So Script 2 might be doing modulo 4 of T, whereas Script 3 might be doing modulo 12 of T. But when working as advertised, they should both come around and agree on where 1 is (rule #1 of Funk!). The ‘bug’ happens when one of the the modulo routines suddenly gets offset by some random amount, and while it keeps counting, the 1’s no longer line up. And no manner of resetting gets them synced up again. Except a power cycle.

I don’t know if this is a clue, but while this isn’t the only time it happens, I notice that when I unplug the keyboard from the Teletype and plug in the Grid this can often trigger the out-of-sync condition.

Thanks for taking a look at it!

and triggering is done by SC.TR.P?
also, how is SC.CV used?

Correct on the SC.TR.P

SC.CV is selecting which slice to play.

There is an added layer of complication in that while my main counter is clicking by at 16th notes, I’m essentially dividing that and creating a new counter that counts beats.

“I” is the bar length in beats, some I’m multiplying by four to get the sample length in 16s, then that figure is in the modulo with T (because T counts 16ths). Then divide by 4 to get the beat (1/4 note) number for the slice to trigger:

SC.CV 5 N / % T * I 4 4

so when it goes out of sync is it the slice that is off?

Yes, the selected slice is not ‘correct’…or in sync with the others (in the other scripts…doing similar calculations).

what about triggering itself, does it stay in sync?

The triggers stay in ‘sync’ on the beat, yes.

ok, so here are all the divisors you are using with T, broken into to primary numbers:

4 = 2 * 2
12 = 2 * 2 * 3
16 = 2 * 2 * 2 * 2
20 = 2 * 2 * 5
24 = 2 * 2 * 2 * 3
32 = 2 * 2 * 2 * 2 * 2
96 = 2 * 2 * 2 * 2 * 2 * 3

if you want all modulo operations to “reset” at the same time you need to use the lowest common multiple as your reset point (as it will give 0 for any of the divisors used). the lowest common multiple for the above is a multiplication of all the primary numbers needed to create the divisors: 2 * 2 * 2 * 2 * 2 * 3 * 5 = 480.

your script resets T at 4032, which is not divisible by 480 without a remainder. what likely happens is that once it reaches 4032 the length of the sequence for the divisor of 20 gets shortened, creating the feel of things going out of sync.

just a theory, and doesn’t explain why setting T to 0 doesn’t fix things, but try changing that line to:
T WRAP + T 1 0 479 and see if that helps.

btw, you’re probably using DEL with triggers to make sure er-301 reads the CV correctly? if your CPU load on er-301 is low you can just do that in er-301, might be more convenient - just insert a delay after SC.TR unit and set it to 100% wet, i think 7ms worked for me to get it working reliably.

1 Like

Thanks for that! I’ll give it a shot.

The 301 is totally maxed for this one. :grimacing:. I did try with the micro delay in there after the trigger, but I’ve had better luck doing it this way.

[The Grid Ops are so amazing!!!]

I had a little more insight into what’s happening. It appears to be an ‘offset’ between the numbers being generated by the modulo function, and the slices being selected within the ER-301. So when things are functioning properly, the beginning of the modulo count, zero, aligns with the first slice in my sample. I noticed that when things get out of sync, the ER-301 is behind by a couple of slices, so it’s playing the second to last slice within the sample when the modulo is outputting zero. I did discover that inputing INIT on the live page and reloading the Scene resets things, which makes me think that it’s an offset that’s occurring on the Teletype side of things on it’s way to the Iici bus.