I’ve got a Faderfox uc-4 setup to do amp levels for each track and it’s working fine when moving just one fader at once. When moving more than one fader at the same time it seems the OT is choking on the amount of cc’s I send it resulting in timing hiccups. I’ve also seen this happening when applying the same setup to my Rytm MK2 or when using a different controller like a Launch control xl.
seems a bit weird as just a couple of CCs shouldn’t cause such an issue. are the controllers you used sending extra CC data? how do you connect them to the machines? any MIDI loop in place?
This seems weird to me, too. I’ve been using a UC-4 the same way you do for a couple years and I’ve never had an issue like that, even if I move all 8 faders at once.
Is the OT your master clock? is it recieving MIDI from anythig other than the UC-4?
If it’s synced to external clock and recieving a lot of MIDI data, it’s possible that you’re running in to general MIDI bandwidth issues (that have nothing to do with the specific gear) and it’s throwing off the timing of the clock signal. But if the OT isn’t syncing to an external clock then that shouldn’t be an issue.
I’m sorry if this seems like a ridiculous question, but you aren’t trying to merge any of the MIDI data together with a simple ‘Y’ cable or something like that are you? Only reason I ask is because I’ve seen other people try and its not something you can do with MIDI (any limited success someone has with it will fall apart immediately when sending more than 1 controls worth of data). It’s the only thing that could help me explain why there’d be an issue, since the amount of data that you describe shouldn’t cause that kind of issue if properly merged.
The only other thing I can think of would be one of the devices being a bad citizen and not prioritizing clock data a as it should … even still, it takes a lot of data for that to become a very noticeable issue. Besides clock and 2 CC#'s worth of data, what else is on the wire? It’d be interesting to see the MIDI captured using something like Bome’s SendSX software.
Initial try was merging with the UC-4, then tried with a Kenton Merge-4, both messed up the clock coming from the Hapax.
I just gave my Retrokits RK-006 a try and it seems to keep the clock stable when clocked from the Hapax and sending the OT cc’s from the UC-4 on multiple channels (tried 4 faders) at the same time.
Adding notes (OT slots triggered) from the Hapax (simple 16 step hats) is too much again resulting in quirky timing. I wanted to program my drums (OT samples) on the Hapax to be able to instantly switch patterns (c’mon Elektron!!) but can’t have it all I guess….
I agree that it doesn’t sound like you’re sending nearly enough data for this to be an issue - unless you’re sending a lot of other stuff tha tyou didn’t mention, a few CCs shouldn’t really cause problems.
Is the RK-006 the first cable you swapped? Mayb the other cable is going bad, or maybe the MIDI output from the Hapax is weak or distorted for some reason - do you have the USB connected to anything (especially a computer, hub or shared USB power supply)? If USB ground noise is bleeding into the MIDI data lines it could cause all kinds of weird behavior. That was a big problem with the original Beatstep.
By default, the Hapax might be sending very detailed CC values. There’s an option to limit the number of values sent per second or something. I also got Elektrons to choke easily using the Hapax.
Just found out the UC-4 was sending cc’s through the Hapax too so doubling the amount of cc’s
Fixing that helped a little but still chokes the OT when not merging via the RK006.
The UC-4 sends cc to midi out and usb midi which is connected to the Hapax. In the Hapax settings there’s an option to run midi inputs straight thru to the outputs which were all disabled except for THAT one…
OK that makes sense. I have the UC4 last in line on the OT inputs, after the footswitch and transport control from the DAW if I’m recording, so I was visualizing your MIDI signal flow that way, for no good reason.