Not sure what the hell was going on with my gear the other day.
It seems one of my OT projects is corrupted in some strange way.
It must have sent some wild stuff to my RYTM making it seem like all the voices died.
I REALLY hope this was just a user error situation.
If that’s the case I’ll be very relieved
Turned on my RYTM this morning with nothing else plugged in and it seemed to be working as it should.
When I plugged in my newly repaired OT into my AK, the AK was wildly out of tune on some projects. I tried figuring it out but it seemed very ghost in the machine.
If it happens again I certainly make a video.
After creating a new project on the OT, everything seemed ok 
However, my OT’s crossfader was definitely put in backwards
I’m surprised they do not do simple tests on repaired gear before sending it back.
That’s two in a row, an unbootable RYTM, and a backwards crossfader on the OT
I was quite lucky today actually.
Logged a bug report at the weekend, and got an email telling me of impending national holidays meaning a longer weekend, but still received a reply relating to the bug and that it’s known and they’re working on a fix.
Well after further testing something is definitely still wrong with my RYTM.
Out of nowhere the voices die.
They sort of crackle after it happens, even caught one on camera.
After restarting a few times it started working again, which is also frustrating, because when it’s working, it’s not easy to identify something is wrong.
Going to just keep putting it through it’s paces and see how it does.
I created a new support ticket Friday.
Not likely
You can set this calibration up yourself, a very simple procedure
Before I sent it off for repairs, if Scene B was lit, and I slid the fader towards B the parameters would move to what I set them for on the selected scene.
Now, the fader works in reverse.
I move it away from the selected scene to to activate the selected scene.
It’s totally backwards.
I’ll post a video tomorrow.
The crossfader can be software reversed, just run the calibration as linked
That’s wild. Never knew that was a thing. If that works that will be excellent
Thank you SO MUCH for setting me straight with this. Had a wild year of gear breaking down. Made my head kind of spin.
Put the OT in test mode, then pressed F+B,
moved the slider far left and right, power cycled, now it’s back to normal.
Sounds similar to my original issue.
But I’ve long confirmed it only happens when connected to overbridge
When booting up, the synth engine parameters and samples of the last used kit would be way off. And there would be no way to reload everything back to its original state.
I’ve also experienced the crackling thing you’re talking about, just not very often
I’m a QA engineer and the way they’re handling quality control flow is not sustainable. They need more people and tighter acceptance criteria and more dev time dedicated to fixing bugs.
I bet it comes down to budget and low priority of these things. That’s usually how it goes.
So far everything is back to normal.
A lot of the issues I was having with my repaired RYTM possibly turned out to be a bad channel on my mixer going out.
Right when I got everything back it was a complicated set up to remember.
There are some minor quirks with my RYTM.
One sequence button sticks a bit now.
My OT has some odd button behavior too.
Everything is bran new on the OT tho, so it may just need to get broken in.
The 1st sequencer button doesn’t always take a press and the green light when switch to pattern 1 doesn’t light up.
Some of the menu buttons don’t take the first press.
Nevertheless I’m just glad to have all my gear back and hooked up running it through the new AHFX
It does happen occasionally and its cool when it works like that. But in my experience, bugs posted here (in the bug threads) are generally ignored because most users are unaffected. And support don’t seem to have time to answer regular queries sent through the proper channel, let alone peruse the bug threads here.
Recent example: i found that the Digitakt’s LFO2 either loses or changes its assignment on powercycle with certain destinations. Pretty serious bug. Reported in DT bug thread and to support. Not a peep from support nor from other users here to confirm the prob.
Im sure theyll get to it eventually. Just hope they dont chuck out a 1.50A release before they see it 
Right, common bug repros can be verified here, but hyperspecific scenarios or those with difficult repro steps may be difficult to collect information on.
