Last 3 positions of micro timing not playing on master reset

Using firmware 1.40A, I noticed something odd when doing a live recording of unquantized midi notes. Occasionally some recorded notes would skip playing on some pattern iterations. So I dug a little deeper and found that this is happening consistently under specific circumstances.

When the master track loops back to step 0, the last step in the recorded sequence that is played right before the master track loops back to step 0 will not play IF that step had a large positive micro timing offset. I realize this might sound a little complicated but it’s very easy to reproduce:

1 . Use a default blank MIDI pattern of 16 steps
2. Place a note on the last step (and make sure you can hear it play).
3. Offset the note using micro timing with a value of +5/96, you should now still hear the note being played.
4. Offset the note one step further to +7/128 and it no longer plays. This also goes for the two positions after that; +11/192 and +23/384

If you do the same with a pattern that has scale mode set to “per track”, and use a 16-step pattern with a 32-step master, you will notice that the note only drops 1 out of 2 times.

I can not think of a situation in which this behavior would be desirable, so I’m considering it a bug. What do you think?

Have you tried doing the same thing in a new project?

I don’t have access to my OT today to try it out but it sure seems like a bug.

The right thing to do would be to post details and follow the reporting instructions in the first post in the following topic:

1 Like

Coincidentally, I spotted last night, on my AR, that if you micro-time (or record unquantised) a trig to play before the start of a pattern, it wont play the first time through, but will play subsequently. This looks symmetric with the situation in the OP.

When you imagine moving a trig backwards with micro timing as moving it into the time slice of the previous step the situation isn’t really symmetric.

What happens when the first step is moved backwards with micro timing is even described in the manual:

If a trig placed on the first sequencer step is nudged backwards, it will be activated at the end of the pattern.

Moving a trig forward with micro timing at the end of a pattern shouldn’t really by a problem (beside voice stealing with a trig on the 1st step), because it will not leave the time slice of the last step. So, yeah, “smells” like a bug (disclaimer: haven’t done any testing by myself yet).

@0x80: have you verified that the midi notes are really not sent, but skipped? For example a slow AMP envelope on the receiving sound generator (if its a mono synth) may also look like skipping when notes are too close to each other …

1 Like

I have just verified that the behavior I described also occurs when I start from a blank project. No note is being sent out. So I’ll consider it a bug and report it in the 1.40A bugs thread.

I agree that moving a trig backwards from the first step is a different situation. I think that behavior is to be expected. If the sequencer starts at position 0 and the trig is moved backwards in time from position 0, it could only play the trig on the first pattern iteration if it was applying some sort of pre-roll time.


I guess I’m thinking like a developer rsther than a UX person here. As the master track has met its end, the sequencer needs to do something to “reset” all the tracks. It’s easy to imagine Elektron implemented this by calling the same processes that happen when hitting stop, and immediately playing again (in time). The queue of future events would get flushed, so the microtimed pushed back events get lost.

Anyway, by all means treat it as a bug. I can see why you expected it to behave differently.

If you imagine every quantized step to take up a fixed amount of time leading up to the next step trigger, then using a positive offset on a step would still locate the trig within the time window of that step. So if that step is the last one before the master reset happens, I’d expect that full window ​to complete its events before the reset occurs.

All of the positive offset values trigger the note before the next quantized step. I tested this by setting the master scale to 32 steps and placing a note on step 0. You can hear both notes playing 50% of the time.

Let’s see what Elektron has to say about this :slightly_smiling_face: I’m pretty convinced this is a bug.

1 Like

Good point. I wasn’t thinking clearly.

1 Like