Arpeggiator Issue

Midihub Support
1

I’m having problems with the arpeggiator when using either the Entirely Up then Down / Entirely Down then Up arpeggiation types.

Seemingly at random, the arpeggiator plays back the wrong pitch and then stops responding altogether. On a few occasions it’s resumed on its own after a few minutes, but I’ve also been able to force it by toggling the bypass.

A few notes:

  1. It seems to be intermittent, but happens after inputing new notes.
  2. I haven’t reproduced the issue with other arpeggiation types (though I haven’t tried them all).
  3. The Midihub editor also seems very sluggish when this happens.
  4. I’ve checked the MIDI monitor and can confirm that the source of the erroneous pitches isn’t my keyboard – it’s coming from the Arpeggiator.
  5. I would say it’s happening every 2–5 minutes.

Arp Preset

2

Here’s a screenshot of the MIDI monitor after this issue has occurred.

Arpeggiator MIDI Monitor
Arpeggiator MIDI Monitor470×753 7.89 KB

1 Like
3

Here’s a preset with a minimal reproducible example.

Arp Preset.mhp (423 Bytes)

1 Like
4

Hey, @echoicMalady,

I ran a version of your preset (with parallel lines for both the two Arp types).
No errors in 11,000 notes over an hours run.

I imagine @Blokas’ @Giedrius might have specific advice about next things to try (apart from the obvious like checking for dodgy cables)

Hope you get it sorted soon.



PS. thanks for all the detail; really helpful

1 Like
5

Thanks for taking the time!

Did your test involve changing input notes? I can only reproduce the issue when regularly changing the input.

I had wondered about a cable issue, but the MIDI monitor shows that the erroneous notes aren’t occurring on the input of the Arpeggiator pipe – only the output. I think the filters should be eliminating any other errant messages.

I’ve found a way of reproducing the issue quickly:

  1. Time Division: 1/32
  2. Type: Entirely Up then Down or Entirely Down then Up.
  3. Repeatedly input a C note while changing the Octave Range up and down.

This should very quickly cause the pipe to play notes out of range and then get stuck at either C-1 or C9. If left, it will eventually return to the correct range.

This is the same behaviour I’m seeing at random when changing notes using these two arpeggiation types.

Also worth noting that I haven’t yet been able to reproduce the issue, even using the method above, with other arpeggiation types.

6

I noticed your error notes were octaves of your true notes; this always the case?

yesterday I just left it running, I’ll see if I can reproduce later with this new knowledge.



btw, I’m not sufficiently knowledgeable to know whether this is appropriate, but it won’t harm to re-flash the firmware…
(you can always do Device → Export Everything… first, although I think the process described does that automatically)


Oh, and welcome to Midihub forums!

7

That’s right, yeah: the correct notes, but the wrong octaves. It seems to be arpeggiating up/down all the way to the octave limit for the input notes. And after a minute or two it will arpeggiate back up to the correct octave range. My guess is that the check to evaluate the correct octave range is failing.

Am I right in saying that the arpeggiation types in question were added in 1.15?

Thanks! It’s a great resource. I originally bought the Midihub for simple routing purposes, but I keep discovering new applications for it :grin:.

8

Yep, see here

9

Hey @echoicMalady
I had a half hour so I set up a little thing to try to emulate your test .

Not been able to break it yet.
If you’re able to record a .mid file of the input, I’ll give it a proper replication test a whirl

(This would ideally involve mapping the Octave Range to a CC, routing both input notes & CC via a virtual out to a USB for your DAW)

10

Thanks for giving it another go, @resonotter.

I’ve attached a new preset using an internal clock, note input via USB and an LFO slowly modulating the Octave Range. With this preset, I don’t need to input new notes to reproduce the issue.

The following steps can reproduce the issue in under a minute on my end:

  1. Input a single note to get the Arpeggiator going.
  2. If there’s no issue within a few seconds, toggle the bypass on the Arpeggiator. Repeat, listening for a few seconds each time until the issue is reproduced.
  3. If toggling the bypass doesn’t reproduce the issue, use the same approach but toggle the bypass on the Rescale.

Arpeggiator MRE.mhp (497 Bytes)

1 Like
11

Thanks for the test patch @echoicMalady

Yes, I can reproduce the breaking of this Arp
Haven’t tested the other new Arp type.



@Giedrius when you get the time, this Archive.zip contains
an adapted version of Arpeggiator MRE.mhp with

  • an adapted version of Arpeggiator MRE.mhp with
    ch16 CC83/84 being used to toggle the Arp & Rescale resp

  • a monitor csv of what’s leaving MIDI D in the preset

  • and a monitor csv of the “inputs” leaving USB-A which are then recorded in a 2nd Midihub

The first csv shows little bursts of low “error” notes which occur occasionally when toggling.

2 Likes
12

Thank you, I’ll note this issue down for fixing. :slight_smile:

1 Like
13

Another issue I’ve noticed with the Arpeggiator:

When mapping to the Repetitions parameter, sending a value of 127 doesn’t update the parameter at all.

To test this I mapped a button on my MIDI controller to toggle between 0 and 127. The parameter didn’t update when sending 127. Sending a value of 126 did update the parameter, however.

2 Likes
14

Replicated: good spot!

1 Like