I changed in my rytm the prog receive setting to no, so now it’s ok but the rytm doesn’t follow the prog change of the digi…
The digi freeze sometimes i have to restart it.
One other issue I am having is as follows: when loading a project, I press play right after seeing the LOAD OK on the screen. However, it seems like it still needs like 0.5 to 1.0 sec to complete loading samples, so what you hear is your pattern playing with wrong samples for a split second. I wish that Digitakt would display LOAD OK when it actually finishes loading 100% of the sample data.
I have had this problem playing on the chromatic keyboard as well, seems to happen when two adjacent notes are played in sequence fairly quickly, one right after the other (kind of in a legato style). Sometimes it happens, sometimes not. Try doing quick little two-note combos, using notes that are physically right next to each other, and see if you can replicate. I was able to replicate numerous times last time I intentionally tried, like a week ago. Can’t tell if it’s based on some very specific timing scenario or the notes being close to each other, or if it’s just a totally random thing, but I was definitely able to make it happen multiple times.
I wonder if it’s something that’s happening to a lot of people and they don’t even realize it because they’re mostly going to be using finite samples that end anyway, even if the length is set to 128, whereas single-cycle waveforms will go on forever.
Might be worth trying to set your sample to just regular “forward play”, not loop, and change it to a sample, not a waveform, then live-record and try to capture a hung note, maybe see if it’s happening with all samples or just single-cycles, or just “forward loop” or something? Might be kind of tedious I guess, but in the name of science! Probably would want to set the default sample length real short, so if you do get a random “128 length” you’ll hear the difference and can go back and look at the recorded trigs to confirm?
Didn’t really think of all this at the time, but I’m gonna go back and try some of these scenarios. Will report my findings. 
Yeah this is how I’m doing it, like you have to “claw” grab the button… like… “YOU’RE NOT FREAKIN MOVING ON ME THIS TIME”
1 Like
I’m hoping for a configuration page to set stuff like encoder acceleration and sensitivity, led brightness and custom colours for each mode and whatever else could be user configurable. But only once the bugs are ironed out.
1 Like
Yes I do hope this gets fixed in 1.10, that’s actually the only bug I have encountered so far Did not push it to the limit with MIDI sequencing, only played with two mono synths at the same time (NYX and 0-coast), all worked fine.
I’m not sure if this a bug or a feature and/or user error but I’m having some issues with live recording tweaks to certain stuff like filters messing up the sound.
To repeat create a new project, new pattern, track 1 a single cycle with amp to inf, place a trig on step 1 and press play; a constant tone that ‘restarts’ every 16 steps. So far so good.
Enter live record mode and do some filter tweaking, once the pattern repeats the amp seems to be messed up.
What I expect: Recording of the parameter I’m changing. doing it manually with trigless trigs works but takes a while.
What I get: The amp or something being messed up. I understand there will some steppyness without parameter slides but something more is happening.
I am doing something wrong or is this by design or a bug?
I recorded some live tweaks of the filter and had similar results. Didn’t sound great, needs some way to make parameters transition between trigs more smoothly. What do the other boxes have? You mention slides?
As an update on my previous problems I have discovered that the D encoder behaves like a fast select for microtiming and as it allready bugs out and brings the src page up without being touched I can only assume it is also responsible for the phantom movements I am battling against whilst adjusting microtiming. I wish they would hurry up and get it fixed, I dont need new features and I have got used to not having working midi but I do expect the 8 audio tracks and the hardware that controls them to work properly.
I don’t think this is has something to do with the lack of slides. It must be a bug. Can’t be that recording some filter sweeps should change the note length/amp settings. If I manually p-lock filter sweeps it works fine. Highly annoying though.
There are missing destinations LFO on track 8, I do not have the parameters of samples (tune, Play Mode, Bit Reduction…) it’s a bug?? or it’s normal??
Just checked on mine, they’re all present on all tracks including track 8. Are they also missing when you load the demo project?
I have all LFO destinations on all tracks
I made a factory reset the same, but I just noticed that it was only on one pattern, really fishy, I copied the pattern from next to it and here it is back
The NEI & /NEI conditional trigs seem weird- like they’re not functioning properly.
I have a standard 4/4 beat just using the BD and SN.
The BD is four to the floor, the SN on beats 1 and 3.
Just for the sake of science I have only the BD on the 2nd and 4th beat with conditionals.
The 2 beat has the NEI conditional, the 4 beat has the /NEI conditional.
What happens is- the BD plays normal the first run of the pattern, but both conditional trig(while being the opposite) fail to trigger on the second run through.
I’m not familiar with the NEI conditionals- but that’s not right, right?
I just did this and the first time through the bar I get Kick on 1,3,4 - the next time I get Kick on 1,2,3.
This seems right to me. The ‘neighbor’ track (the N of NEI) is track minus 1. So I’m guessing track 1 has no neighbor track since track 0 doesn’t exist, and the neighbor is just itself. It’s behaving as expected in that way.
If for some reason you’re talking about the SD on track 1 and BD on track 2… I get kicks on 1,3,4 for every bar. This would seem to mean that because the neighbor track (1, SD) has no trig conditions, the default comparison results in ‘false’ for beat 2 (NEI) thus no trigger, and then false again for beat 4 (/NEI) thus a trigger. Again, this seems correct.
2 Likes
I guess I shouldn’t have tried it on tracks 1 & 2. I’ll try it again in the center.
I can’t comprehend how 1, 3, 4 could be correct if it’s NEIing itself.
Will redo the experiment and see if I can figure it out.
Thanks for your response
Oh shoot! I just tried it on the middle tracks and it works as expected! That is COOL! I just discovered the thrill of poly rhythms and this conditional is going to be put to use! Thanks again for your help!
1 Like
Wait- no, this is weird. It plays the same pattern and then i change some trigs around- it plays the same pattern, I press stop and play and it changes?
If it’s NEI of itself, then it’s always looking at its own previous conditional trigger evaluation. The first time it hits one (beat 2) there is no previous conditional trigger so it’s false and on an NEI trig, so there’s no trigger. The next time it hits one (beat 4) it’s looking at the previous trigger from beat 2, which was false - but it’s an /NEI so it’s a trigger. Then the next bar those would be reversed because the next Beat 2 NEI would be looking at the previous bar’s beat 4 which was true, so it is also true. and so on…
The manual doesn’t say track 1’s neighbor is itself, but I’m just thinking it must be because of that behavior… if it was just looking at a ‘blank’ nonexistent neighbor track, then it would be 1,3,4 every time.
2 Likes