I have a powered hub I can try when I get home from work. I was in the middle of testing Mononoke in standalone (no AU hosting) and it had been running for 30 minutes without issue. I was really hoping to avoid using a hub. The Type C port on the Pro model is really sensitive to bumps and nudges, often disconnecting with even the slightest touch. I’ll report back this evening. Thanks for the suggestion!
Same happened with VCV Rack. But starting a new project seems to have rectified this problem.
Setting up a new project on the DN seems to have fixed this problem
that depends on whether the sending app is limiting the rate of updates - some will send at a high rate - LFOs aren’t necessarily monitoring shape changes - remember that teh phase of an lfo isn’t always coincident with a note event - so an active flat lfo still needs to transmit its value periodically
anyway - just pointing the discussion towards the potential reason for the issue (this is not new to this new OS afaict) - i vaguely recall this being officially discussed so there may be some insights elsewhere on the forum from one of teh Elektron contributors
After updating to the 1.3 version, overbridge isn’t able to connect to my digitone. I’m running the latest version of overbridge (2.0.39.10). My other elektron boxes are represented in overbridge though. I even tried re-installing the 1.21 version back on the digitone, sadly with no positive result.
1 Like
you really shouldn’t btw and this is not a bug - this is more likely an installation hiccup for which there can be a myriad of explanations - methodically following the uninstall/reinstall process is the first steps - rolling back from a major os update shouldn’t be done lightly - you can break projects that way
2 Likes
Thanks for the tip, I’ll never try that again 
. Maybe re-installing overbridge will do the trick.
…re-installing overbridge solved the problem!!!
1 Like
i understand that they are but there’s no word on when or how this will be resolved - that bus may have passed until the next one, it’s hard to know when updates may come, unless something is considered critical
Just tested with a powered USB Hub (see link below). Audio stopped within 5 minutes. Tested with the steady drone and with a synth being sequenced by the Digitone.
This is the hub.
I have another powered hub I can try but the one above I’ve used with a 2nd Gen. Focusrite 2i4. No issues. Same with a Steinberg UR44. I haven’t tried with the Analog Heat MKII.
I found a behavior that before the update didn’t exist
With the new update it’s like the enconders are ultrasensitive, and example would be, if you push down the encoder really fast to reduce the entire reverb send instead of keeping the value of 0, it jumps around to a different value. It’s like the machine has more room to detect the moves of an enconder when you are releasing it, I don’t really know how explain it. It doesn’t happen all the time but enough to annoy me.
I only tested on the DT, i don’t know if the DN it’s working like that too
it is and it has been mentioned - it seems to affect value display and on occasion the value when the encoder is still rotating when the press is released - it can be disconcerting to turn the value down to 0 and see it temporarily appear to raise back up a 1/3 of the way - i think it is undesired/unexpected behaviour
Anyway - this is a DN bugs thread, but presumably this will be mentioned in the latest os DT bugs thread
1 Like
Wow sorry, I had a lapse, and i thought this was the Digitatk - Bug Report Thread.
Anyway I hope this will be resolve
2 Likes
I think I have the same issue as you: I’m using a few modulators in Bitwig on the OB DN plugin and it just takes two, maybe three of them (LFO, ADSR) to basically make the DN unrespsonive. It will either crash out entirely, or lock up. If I remove the modulators it will sometimes recover, but mostly it needs a full restart. Very frustring: I’d love to control as many parameters as I see fit, and having it lock up after even just 1 or 2 seems…terrible.
2 Likes
Found some issues with the “Poly (Mono-LFO)” voice mode that seem quite buggy.
With the LFO in “Free” mode, it works as expected, all the voices use the same LFO modulation which is great. However, all of the other LFO modes (which are triggered) seem to be buggy, seemingly because the “LFO Trigs” are only having an impact when a certain voice is triggered. It seems like “Poly (Mono LFO)” mode is only utilizing the LFO from a single voice (which is as it should be), but it is not routing all the LFO trigs to that LFO, so many of the LFO Trigger events have no impact.
Take, for example, “Hold” mode: My expectation, as a user, is that in “Hold” mode the same LFO should be sampled with each new LFO Trig, so that the same modulation signal affects all the voices equally, while the sampling occurs with each new trigger. What ACTUALLY happens, though, is that the LFO valued is not sampled on every trig - it’s only sampled when a certain voice (I assume the one the LFO is originating from) is triggered. So if you have a sound with “Poly (Mono LFO)” voice mode, and a “Hold” LFO, and you play a melody in, it’s pretty random when the LFO will sample a new value since the trigs are not happening on each keypress, but only on keypresses which trigger a certain voice.
The same issue goes for the other triggered LFO Mode - with “One” , and “Half” , modes, I would expect that all voices share a modulation signal from one LFO, but that the LFO/envelope will be triggered with each new trig, not just when one of the voices is triggered. I’ve not thoroughly tested “Trig” mode yet so I’m note sure if it also behaves this way but assume it does based on other mode’s behavior.
Hopefully this makes sense, it’s a bit of a let down since I was quite excited about this mode but it doesn’t seem to be working intuitively 
i’m not entirely sure why you suggest it’s a bug when you measure it against intuition - having said that, it’s my estimation based on intuition that it’s working as i expected it to - the modulation phase is set by the first voice, say the first note in a triad - i don’t see any other way to anticipate what happens when you add to that note than to imagine the next notes take on the same phase - there is no trigging of the LFO, that would be potentially messy
you want the LFOs with a trigged phase component to adjust for every successive note, whereas the LFO die is cast when the first note is held
maybe you could ask for an additional mono with reset mode, but it doesn’t seem buggy or a bug to me - this is evidently what was intended - whether it follows convention or not (or each user’s expectation) is another thing
a resetting mono mode option would still be welcome but i think they went the right way, it’s more akin to a legato mode - it all happens on the first note down, that’s when the LFO is set, feels quite musical to me and it avoids obvious/jarring lfo phase jumps when notes are added - ymmv
1 Like
Ya, I’ve noticed this one too. It’s a little disconcerting.
Running into an issue with midi tracks. Example, if I am editing trigs on page 2/4 on midi track 1 and switch to midi track 2, it resets the page to 1/4. I believe in the past it would stay on the same page when switching between tracks. Can anybody else test this?
I’ve also experienced the audio drop outs using class compliant mode.
I tried using it with Ableton Live on my 2011 MBP. It’s a fairly light project - Digitone Keys stereo in, a few effects and Drumracks returning, using the DK as monitor outs.
The audio just stopped after 15-20 minutes playing. Restarting Ableton got the audio back for another 10 minutes or so.
I’ve repeated it a few more times, the audio always stops eventually.
The same project plays fine using the DK as sound card in Overbridge mode. (I’ve not tried using the plugin).
Thanks for this response! You’re right, I didn’t make the connection that the poly mono lfo mode was working like legato, based on when notes were overlapping sharing the same lfo! It’s a really good implementation actually, wasnt able to grok it because I was using a track with lots of overlapping trigs so the lfo trigs seemed to be happening randomly. A mode which does a lfo trig every note event could still be interesting as an alternate mode, but as it is the implementation is fine actually. Thanks for clearing that up!
1 Like
Experiencing the audio drop outs in class compliant mode as well. Using an iPhone SE with AUM, everything works perfectly until audio stops streaming to the Digitone after a while.
Note, Digitone is still streaming audio correctly to the phone in the meantime (I got a usable recording). Unplugging/replugging the USB cable fixes it.
1 Like