Yeah… really looking forward to this getting fixed. Compared to OG DT, line inputs are so quiet. I have to crank my incoming volume to the max
4 Likes
This is the one bug that’s really holding me back at the minute.
I see something similar on the Machine screen - everything to the left of the white bar with the currently selected machine is dimmer.
Seems fine otherwise, and no permanent lines.
Presumably, once sampled, you can then re-sample to boost the volume ? Because on re-sampling normalisation kicks in doesn’t it ?
You don’t need to resample because the DT auto-normalises making the sample much easier to work with than the live audio.
I guess some synths won’t be affected so long as they have a high output level but it’s easier to clip in that case. Of course, you can use the sample screen to check the actual incoming levels are suitable.
Edit: maybe I misunderstood., the auto-normalising is done on all samples that you record.
1 Like
My screen lines problem is permanent now…
Gonna send it back for repair 
…
Extremely frustrating since it might be the best gear I got in years … and I bought a lot!!
did the format and re-loaded about 8 gb of samples back in - things started to get wonky after that with freezes caused by re-sampling/saving. definitely gets worse with increased storage use.
ended up formatting a second time and now limiting myself to factory sounds and recorded samples from my synths, not using transfer or my sample libraries at all for the time being.
i’m really anxious it’s a physical issue and not software/drive management in the OS.
anyone gotten info from elektron? chloe seemed like she already knew about this bug.
hopefully they’ll be able to at least identify the cut-off point and if they can’t fix it implement some sort of hard limit with a software update.
1 Like
How to set levels properly with auto normalize?
Hey all -
I think I may have discovered one that hasn’t been mentioned yet. It looks like some mixer page settings aren’t updated upon a pattern change until/unless an audio trig is played by the sequencer.
Steps taken in my project that have produced the bug:
1.) Set up an external device into the LR inputs and configure midi output to the device.
2.) Set up a midi track on the pattern with sequence data and turn the “IN LR” setting in the mixer subpage up all the way.
3.) Copy the midi track and sequence data to a different pattern that has only one audio track with trigs, and make sure the audio track is muted (makes it easier to see the bug with just one track).
4.) Ensure this new pattern has the “IN LR” setting turned all the way down.
5.) Switch back to the original pattern with “IN LR” turned up, play the track and confirm you hear audio from your external device.
6.) Switch patterns to the one with “IN LR” turned all the way down and you end up still hearing your external inputs in the main mix despite the mixer setting with a volume of 0. Unmute the track that has the audio trigs on it and you’ll stop hearing your external inputs after that.
Took me longer than I’d like to admit to figure out it wasn’t my midi data getting cut by unmuting the audio track so hopefully this prevents someone else from spending time figuring out the same thing. Opened up a ticket with Elektron and sent a video.
1 Like
I think there will always be a change due to the normalising. I was just talking about being able to monitor against whatever you are working on in DT. Some synths are too quiet with the current inputs.
1 Like
i’ve been using usb sync from ableton and couldn’t work out why oneshots were so out of sync. Then tried midi sync using an external clock and its perfect now. So for now it seems USB midi and audio is unuseable. Pity because with OB on the syntakt and A4 it works perfectly.
Same thing happened to me today, only had it 2 weeks and lots of horizontal lines across the screen when I switched it on today.
One of the bugs discussed here is an issue that I’ve encountered when seemingly arbitrary samples are inexplicably tuned down
At one point when he’s demonstrating the music that’s being worked on, one of the LFOs stops working
He mentions that he’s apprehensive to use the DT2 in his live set due to the potentially show-stopping bugs that are still in the unit
That’s not good
I’m just a hobbyist and am mostly untroubled by the weird quirks, so I haven’t considered the perspective of being a professional musician trying to use the DT2 live. If I were a performer, I wouldn’t risk using something that consistently exhibits behavior which could sabotage my set
Hopefully everything gets ironed out soon!
1 Like
Same here, happened during practice last weekend, left me completely puzzled.
1 Like
Can anybody reproduce this? Elektron Support couldn’t and I myself wasn’t able anymore.
Have you checked the Pichbend for the specific tracks? DT2 tends to default to 64 instead of 0 after using pitchbend…
2 Likes
I use the midi thru port as DIN24 and many times I have to re-enable it after power on
Indeed. That would also explain tuning problems…
Edit : it goes between 0 and 128 instead of +/- 128.
2 Likes
Can anyone else confirm this?
When setting the delay feedback with the D encoder, it skips numbers. This consistently happens. It does not seem to be a problem with the encoder though as the knob functions as intended when using it with other parameters.
Edit: Also why does the delay feedback go from 0 to 198?
OK, something is wrong with imports OR there is a bug / initialization issue with the new file hashing function. Basically, my understanding is that the DT creates a (supposedly) unique hash for each sample filename imported, so that if you ever move or rename a sample, it’s still referenced properly. Unfortunately, importing old projects and samples using the built-in method (I chose only used samples, leaving unused samples out) results in some samples being loaded into multiple RAM slots. This shouldn’t be possible, and isn’t in a new project, but it caused many unexpected samples to be loaded into the SRC parameter for me in older project patterns. Sometimes, it will show it’s referencing a particular sample name but play a different one. The only way to fix it is to navigate directly to the Samples menu, look at the slots in the RAM, choose the offending duplicate slot, unload the sample, and replace it with the sample you want (even if it’s the same one).
This took me about four hours today, but I think I’ve tracked down most of the offending patterns and they are all a bit older - so perhaps projects created on older firmwares are more susceptible to this behavior. No confirmation from Elektron yet, but this is probably an edge case for them. I’ve offered to provide files and/or to join the beta list with no response. Hopefully this doesn’t indicate a problem with collisions (multiple files having the same hash value) for projects moving forward.
If this bug report isn’t detailed enough, I don’t know what is.
1 Like