*SOLVED* Pad noise / glitchy

[FolkDub]

Howdy friends ~

I didn't see this issue in search; I'm open to some diagnostic effort to solve.

NDLR (master clock) USB1---> A/mrcc --> DIN/Blofeld (module)

Also m-audio axiom49/USB --> D/mrcc
(Also 3 other hw synths (diff channels) on DIN/mrcc rec'v notes from NDLR)

when playing Blofeld as Pad (lfo moving position), with/without other parts playing, no other inputs, there is sporadic digital noise (a'la clipping or glitching).

voice limit? (No) Can play Blo w/ keys and press all of them with my arms.... No glitch.

Can reduce pad spread down to 1 note, still glitch. Strum has no impact to glitch.

Get this: pad may be *disarmed*, and play drone on same channel (Blo)... When moving *Pad* position (still disarmed), glitches on drone sound (no changes to drone part).

Get this: it doesn't happen on every blo preset. But I've found it on some Pad presets. But only w/ NDLR as input (not keys).

Haven't tried to capture midi traffic, but it seems like pad part is sending itchy data during position movement (lfo or manual).

Anything i should be looking out for?

-=FolkDub=-

[Jesse Johannesen]

So Pad position may be sending a MIDI CC message on that channel, I don't remember if that happens or not, but if you have an MRCC handy you could try loading the factory preset and only route the NDLR to the Blofeld, then go to the MIDI Monitor, and unpause it, then turn the encoder for pad position and see if it's sending CC, if so look at what that CC goes to on the blofeld and see what it's tweaking. You may then choose to put a CC filter on that routing if you want to block those kinds of messages from coming through and giving you problems.

[Darryl]

Other possibilities:
Pretty weird that the PAD control affects the Drone sound. MIDI notes being sent from NDLR is just MIDI data same as the keyboard, so probably most likely an electrical issue. There could be ground noise/loop. To isolate, try disconnecting all devices from computer USB if they are connected there. Try powering all devices from the same power strip. Worst case, you can try a USB ground loop isolator on the MRCC USB PC client port or NDLR USB. Search "usb ground loop isolator" on Amazon.com for examples. I have some bad ground loop issues in my basement office, so use an iFi Defender on my USB audio DAC.

Try turning down the velocities on NDLR Settings menu 2.

I've personally used NDLR and Blofeld together a lot, and hadn't noticed any distortion in the sound.

[FolkDub]

Thanks for the input, CL Team.

In my efforts to better diagnose/define the problem factors, along with the suggestions provided, I did stumble upon the culprit.

No midi CCs showed on MRCC during monitor of PAD changes , no "non-note" midi input indicated at Blo (LED) --  even with distortion audible
Pad Velo (Menu/Settings 2) had no impact - - buuuuuut, when exiting out of menu (after changing velo), it glitched briefly ?!

(explore explore explore) --

All PAD commands (knobs 1,2), Menu/setting2, and TEMPO induce glitch
No other devices or Control inputs (Drone/Mot1,2, Chords, Key, Mode) induce glitch

'cause --

 it's the Clock. (NDLR as Master clock)

    --and ---

 Blofeld patches which use fx: CLK.Delay  (timed/sync'd delay).  Change CLK.Delay to regular delay - boom. Always clean, under any circumstances.

So it is an 'integrated' problem -- NDLR as clock and Blo/clk.delay. Easy enough work-around (change delay, or maybe change clock source (haven't tried)) . . .. but do you 'expect' PAD changes (even LFO driven) to 'wiggle' the clock?

[Jesse Johannesen]

You also have an MRCC so you could theoretically just filter clock on that specific routing, unless I misunderstand, but either way, great news. Congrats on solving the mystery.

---

Also thanks for following up!