"One in..." Math trigs don't reset when stopping playback

Basically “One in…” Math trigs (1:2, 1:3, etc) seem to work by keeping a counter that increments every time the note is supposed to trigger, and the note is allowed to actually send MIDI/CV if the counter is on the right number. However, that counter seems to not reset when playback is stopped, so if you play half a pattern, the counters of notes in a pattern with the same type of “One in…” Math trig will get desynced, giving different results every time.

The counters do reset when restarting or reloading a project.

Let me know if you think this is a bug or a feature.

Scenario 1:

  • Create a 1-bar pattern.
  • Enter 2 notes (preferably different pitches to distinguish them) using the 1:2 Math trig, one in the beginning of the bar and one in the middle.
  • Start playback.

The two notes both play on the first pass of the 1-bar loop, and they’re both muted during the second pass.

Scenario 2:

  • Create a 1-bar pattern.
  • Enter 2 notes (preferably different pitches to distinguish them) using the 1:2 Math trig, one in the beginning of the bar and one in the middle.
  • Start playback.
  • Stop playback before the 2nd note triggers.
  • Start playback again.

Now, on the first pass of the 1-bar loop, the first note will be muted, while the second one plays. On the second pass of the loop, the first note plays while the second is muted. They are not synchronized anymore.

If you stop playback between the two notes again, and start playback again, the notes will go back to being synchronized, both playing during one bar and both being muted during the other.

Scenario 3:

  • Create a 1-bar pattern in pattern slot 1.
  • Enter 2 notes (preferably different pitches to distinguish them) using the 1:2 Math trig, one in the beginning of the bar and one in the middle.
  • Copy pattern 1 to pattern 2.
  • Set pattern sync to 1/2.
  • Start playback.
  • Switch patterns between the two notes.

Now the notes are desynced again, and we never even stopped playback, just switched between two patterns.

Why it matters to me:

I tend to stop and start playback often, and if I have a fill programmed to run every 4 bars using the Math trigs, and happen to stop playback during the fill, the fill is now messed up and half the notes of the fill are going to play on the right bar while the others will play on a different bar, until I reload the project.

Another case that it may affect could be having similar patterns with Math trig fills, and switching between them during a fill could result in their fill notes being desynced for the rest of the song.

1 Like

I hope that’s not the way it’s supposed to work and they fix it so that the conditional trigs stay in sync.

please report via the contact form , this is best discussed with devs.

to me
scenario 1: seems ok

scenario 2: Id need to do a test, is this doing a restart or a continue?
if continue, then I think its as expected, if its a restart I think its a bug
(does double stop change behaviour? which I expect to be restart)

scenario 3: where does new pattern continue from when you switch?
again, if its ‘continuing’ where p1 left off, sounds like the behaviour is correct.
if it was restarting, then a bug…
importantly, have you tried changing track trig between free/restart.

overall, I think the behaviour should be…
if its continuing, then maths indeed NOT be reset.
however, a restart means maths should be reset.

but again, discuss with devs directly , they are best placed to look into this.

1 Like

I’ve had related math issues, and have already had some correspondence with Squarp. This is what I sent them:

I’ve noticed a few issues with math:

Issue 1: Math isn’t reset when a pattern is restarted, even if I have the pattern set to Trig: Restart. For example, when I press Stop in the middle of a pattern playing and then press Play again, or when I re-trigger a pattern by pressing its button in pattern view. I expect Hapax to always reset each note’s math whenever the pattern is restarted, due to pressing Play, launching a stopped pattern, or manually re-launching an already-playing pattern.

For example, I have a 2-bar drum pattern with a 1:2 math hihat note on beat one and a 2:2 math hand clap note on beat one. If I press Play, I hear the hihat note. Now if I quickly press Stop and then Play again, I hear the hand clap. This toggling repeats every time I press Stop and Play again. The same thing happens if I manually trigger a pattern restart by pressing the pattern button in pattern mode before the first measure has completed.

In another example, I have 16th note hihats all set to 1:2, and I press Stop halfway through playing the pattern. Now, when I press Play again, the first 8 hihats are out of sync with the second 8 hihats.

Issue 2: Changing note math when Hapax is playing can result in note state getting out of sync with other notes. Stopping and restarting the pattern doesn’t fix it, probably because of issue #1. Once out of sync, I have to delete and re-add the notes before they will be in sync again. I expect the position of the playhead to not affect note math while Hapax is playing, so that setting note math works exactly the same while playing as while stopped.

For example, I have a drum pattern with start and end loop points set so only the first beat (4 sixteenth notes) is played, and I have a kick on beat 1 that I’m using as a reference. I also have 4 hihat 16th notes with no math set. When Hapax is stopped, if I change the math of the 16th notes by selecting the row and turning the math encoder to 1:2, then press Play, it works like I’d expect. However, if the notes have no math set, and I select the row and turn the math encoder to 1:2 while Hapax is playing, some hihats will play the first time, and some will play the second time. It seems to depend on where the play head was at when I set the math on those notes. It’s super inconsistent.

Along with a few related feature requests:

Feature request 1: I’m finding it super hard to look at a pattern and figure out what math setting is currently applied to my notes in a pattern. Is there any way to highlight all the notes that are using the currently selected math setting? For example, if I set the default math setting to 1:2, maybe all the notes that have a 1:2 setting can pulse, or blink, or be a brighter color than the other notes? Maybe notes that have the 1:2 setting would be brighter in the OLED screen, while the other notes would be dimmer?

Feature request 2: Related to #1, would it be possible to highlight Fill notes when the Fill button is held down in some way, so it’s easier to tell which notes are Fill notes?

Feature request 3: Can notes entered while Fill is held down have their math mode automatically set to Fill?

And they responded saying the bugs had already been caught and will be fixed in the next OS release, and that some of the features I requested were already planned for a future update.

I encourage you to report your issues as well, in case your descriptions help them fix the problems!

2 Likes

Yep, I was throwing it out to the community before I submitted a formal request about it, to see what other people think of it.

scenario 2: Id need to do a test, is this doing a restart or a continue?
if continue, then I think its as expected, if its a restart I think its a bug
(does double stop change behaviour? which I expect to be restart)

Both single and double stop restart the pattern, and they both cause the “desync”

scenario 3: where does new pattern continue from when you switch?
again, if its ‘continuing’ where p1 left off, sounds like the behaviour is correct.
if it was restarting, then a bug…
importantly, have you tried changing track trig between free/restart.

I’m using the “free” track trig, and the pattern is continuing where p1 left off. This was my intention. I like to work with free pattern trigs rather than restart, but I understand that they’re just different workflows. Using “restart” seems to dodge the issue on the p2 side, since p2 starts from the beginning, but going back to p1, the notes in p1 are desynced, since p1 was cut off early.

I agree with your assessment. Thanks!

1 Like

Glad to see someone else found out about this too. Thanks for all the info, my use cases that are affected by this are very similar to yours. Your feature requests are really smart too!

I’ll also be reporting my issues. Thanks!

1 Like