Hi there,
am I the only one experiencing lags when using an external midi controller with digitakt 1? especially when using multiple volume faders on the UC4 faderfox the digitakt playhead stutters and sometimes theres even audio dropouts. does this problem exist on digitakt 2 as well?
it also occurs when directly connecting the digitakt and UC4 via midi with no external devices present. digitakt should be able to handle the input of an external midi controller? thanks for all your help…
At least one person, same controller, no problems.
I assume there are others with the same. Generally, a lot of people are using midi controllers with Digitakt 1 without issue.
So it’s a ‘faulty unit’ ? Maybe someone of Elektron could chime in to see if there’s anything that can be done. I heard of a few people that have this issue with other midi controllers than UC4…
On the upside the global mutes work as expected so I can always mute tracks before changing patterns. Also I might put all track levels to zero before saving a pattern so at least it’s silent when changing but nonetheless quite a shame 
Have you tried a different cable just to be sure? Are you using a midi thru device normally or how is your stuff set up? Are you on the latest OS and does this happen in every project or just the current project? If not, try a new project with just arbitrary sounds, doesn’t have to be a real track, see if the behavior is repeated. Are you using the stock power supply? Can you measure the voltage coming through to make sure the power supply doesn’t have issues?
I’d just try stuff like that in trouble shooting, no way to know if either unit is faulty until you eliminate enough things that it can start to point in one direction or the other. Different people with similar problems aren’t necessarily your problem, so when I try to troubleshoot anything, I look at the problem I’m having and definitely take in any info that I find, but I don’t stop looking for the cause of my problem.
If you try any of those things and can check back with the results I’ll see if I can think of anything else but even things that seem obvious are good to eliminate first.
Hey First Off massive thanks for your time and suggestions.
What seems to improve it a little is the direct connection leaving out the iConnectivity mioXM, not significantly but a little (which is worth a lot already).
Any other ideas welcome…
What I also noticed is that digitakt runs much more smoothly with the external controller when set as the master clock.
Cheers again
Hey, I don’t know about the transport stuttering because that’s pretty strange for digitakt, some of what you’re describing sounds like there’s a data bottleneck or potential midi feedback. Is anything plugged into the midi in port on the faderfox or just the midi out? If something is running into the FF in port, just unplug it.
You could try both the digitakt and the faderfox connected over usb through your daw, since usb midi has a higher transfer rate than serial midi does, it might show you whether or not that’s the part of the problem (too much data coming faster than DIN midi can process it). If it’s no more stable than previous tests and the issue persists over usb you might also want see if there’s something in the documentation for the FF about hardware acceleration on the midi controller (maybe UC4 has a config app?).
I’m not that familiar with how setup and update work on faderfox devices but you may need to disable any acceleration (if there is one). Or, In the event that it has turbo speed midi, you’d need to enable that feature in the dt menu to be able to make use of it and then that would definitely speed up the din connection (I’m not expecting FF has this but since DT does, it’s worth checking).
Another thing is since I don’t implicitly know how many faders you’re moving at once on the UC4 when the lag occurs, but as a test I might try one fader at a time or combinations of them and see if a single one (or combination) is problematic. Just try and see if there is any predictability or recognizable pattern to the conditions which cause a problem to occur. If it takes like 4 or more controls moving at once to glitch it out, I’d say that probably points towards either the aforementioned data bottleneck or possibly some other firmware compatibility issue.
As stated previously I don’t know much about the faderfox but if it has USB it probably has firmware so I’d verify it’s all up to date. For the Elektron side, 1.51A is the newest DT firmware on the website but I’ve seen people using 1.51C for digitakt 1 so Elektron has done a soft release for at least firmware versions B and C, if you want to be really sure this isn’t an issue you could contact support and ask for a file to be sent so you can update, but my suspicion is that this isn’t the issue.
I’m assuming the faderfox doesn’t have any problem with other gear and neither does the digitakt, so it’s just going to be process of elimination until you have some hard evidence of a problem. I’m less inclined to believe that this is the result of either unit being faulty but it’s difficult to know for sure, especially when other people using similar (or same) controllers have no issue. Makes me think it has more to do with the conditions under which it’s being used or intermediary factors such as the mioXM, cables, data arriving faster than it can be processed, midi feedback etc.
Another thing you could also try, is instead of auto mapping each FF knob or slider all at the same time (I assume you have to do that once in the beginning and store a profile or something), start by assigning only one slider/cc/channel, using it, then assign another and use them together etc. With only these single assignments, see how long digitakt takes to respond negatively, then drop the other midi channels and focus on just the one that introduced the jitter (meaning if it doesn’t happen until you assign and move the 4th fader, focus on whether that one operates normally without the others involved). If it behaves itself when it’s the only one that you’re using or have mapped, then that again would point towards some kind of data issue.
If the amount of data coming through exceeds the speed at which the standard hardware can process it via DIN connection, that would be less a problem with digitakt and mostly just a limitation of the technology. Standard midi protocol has remained mostly unchanged since the early 80’s so you have to assume some limitations to the bit/bye architecture will exist.
I’m not trying to discourage you from attempting to work on the issue but also prepare yourself for the possibility that there may be some limitations which can’t be surpassed, at best worked around. That would mean that if you observe no matter what you do, sending more than 3 cc’s in tandem causes problems, then that may be the limitation with this hardware setup and to avoid it you’ll have to work within those constraints. I just picked that number arbitrarily so don’t read anything into it, I’ve never known DT1 to have an issue with a specific number of inbound CC’s but until proven otherwise, there’s always a possibility.
That’s everything that I can think of right now, I’d start by trying both connected by USB midi with your computer acting as host and see if the problem is somewhat alleviated or if it’s the same results and then move forward from there until you have some clear idea of what makes it worse (like how you discovered the device providing clock sync info matters).
Good luck.
Hey there,
what a thorough response, that’s class, thank you much!
so I connected the UC4 and Digi via USB host of the Mio and no real difference to a direct midi cable connection between the two, but def better than routing through the din ports of the Mio.
Then Ill have a browse and see if I can find firmware B or C somewhere but agreed thats like not gonna change much.
The issue occurs when moving at least 4 or 5 faders simultaneously so that might just be the limitation of midi. Digitakt listens to different channels per track so track 1 = ch1, track 2 = ch2 a.s.o. so UC4 is sending data across 8 track channels, plus the fx channel.
The main issue is really that digitakt absolutely does not like to be the clock slave. Whenever it is slaved it totally glitches out when UC4 channel faders are moved (btw. theres no acceleration for the faders, only for the encoders).
So but when digitakt runs as master with internal mixer fx enabled then its usable. When disabling internal mixer fx then it runs butter smooth even with all 8 faders moved at the same time.
so the issue from my pov is clearly some buggy (or perhaps limited) firware in the digitakt that created some sort of midi feedback loop with internal mixer fx enabled in global settings.
This issue had been raised across other boards as well but Elektron does not seem to address this. I will send them an email about it actually and see what’s their take on it.
So I got a couple of options here, namely disabling global internal mixer fx for the recording session when midi is slaved to ableton.
On another note I was thinking to have digitakt as the master and ableton as the slave but the issue is that i cannot change the midi position pointer data in the digitakt so ableton always resets to the arrangement start upon stopping the digitakt. Other people have successfully sent SPP data to the octatrack so that would be cool to do with the digitakt too but thats a different topic alltogether.
Once again thank you for your time and help. Much appreciated!
Master vs Slave behavior makes sense to some degree, maybe not the degree you’ve described it but if you imagine all of that data being moved at once, then the clock data becomes part of that stream and adds to the congestion. Also, for us, milliseconds are difficult to measure by perception alone but where we’re talking about a limited number of bits and bytes that can flow through the pipe before it exceeds the potential for the transfer rate, then constantly receiving clock data is going to take up a solid chunk of that because for machines milliseconds of timing can change everything.
Also, I don’t know how the faderfox software is written but in order to ensure that streaming updates to knob/fader parameters are made in as close to real time as possible, it may send out a confirmation of the knob and fader positions with some kind of regularity even if they haven’t moved.
You’d have to send the UC4 through a midi monitor and see if it’s constantly or at some regular interval emitting a midi data stream, like sonar pinging for location, or if it goes dormant when untouched. That would also help confirm whether or not the FF data density could be confusing DT.
There is, of course, also the possibility that the DT processor isn’t optimized for this kind of midi traffic, and you might be right that there’s a glaring opportunity for Elektron to improve upon the behavior. If the amount of data going through really bogs when the FX are engaged, then I would not dismiss processor limitations, but at this point I think it’s best to give Elektron all the specific data you’ve been able to confirm through this and see what they say.
I’d also be interested to hear the answer as well, because this is all (at best) just making educated guesses. Luckily though, the more causes you can eliminate, the easier it becomes to start making guesses in the right direction.
If you have a chance, you should update this when you hear back from support.
This issue can only be three things:
I’ve subjected the Digitakt to a whole lot of MIDI data and it’s almost impossible to choke it over USB, let alone DIN. I’ve only seen this behaviour when I flooded the MIDI buffer with 8 channels of constant NRPN over USB.
Under normal circumstances the Digitakt should have no problem with more controls than you could ever touch at the same time. It handles 8 channels of combined CC, NRPN and NOTE messages without issue, including MIDI Clock.
That is over USB, but even when sending all that over DIN and exceeding the bandwidth it still works, just late. In other words, even a stream of constant MIDI data over DIN shouldn’t choke it.
I’ve never seen external MIDI Clock make any difference, USB or DIN.
Disclaimer: I’m not on the latest firmware.
Thanks for chiming in.
Have you had the internal mixer settings enabled in global settings of the digitakt?
It’s really this one setting that causes everything to fall apart. I think what happens is that internally there’s some kind of feedback loop with this setting engaged or maybe the routing gets a little weird. I sent Elektron a mail about it and will report back but no nrpm going on anywhere just simple cc msgs without acceleration.
I have now settled for keeping internal mixer in global FX disabled until this is resolved. If anyone has this setting enabled on an older fw and does not run into the same issue then maybe that’s something that came up with a different feature along the way.
Probably not, I don’t think I’ve ever used this feature.
If this only happens with this one setting it’s most likely a bug in the Digitakt.
The only other thing I can think of is checking the MIDI channel settings. Some functions have overlapping channels by design, you could try changing the settings to see if it has any effect on this issue.
Control accelleration has no effect on this kind of issue, or any MIDI hardware issue. Accelleration only changes the response curve of the control itself.
NRPN messages just take up more bandwidth(4x compared to CC). On a controller with NRPN and a DIN connection the worst that can happen is that your controls become less responsive(more grainy response) because it takes ~4ms per message to transmit.
I think the firmware on my Digitakt has the Global mixer feature so I’ll check if the bug is also present there. No time now but I’ll try to report back.
Hey there, so Elektron replied to me asking me to do video demonstrations about this issue. Here is a copy of my mail I just sent back to them. Test 2 highlights the Issue and its ultimately proven that its a problem with ext mixer settings enabled in Test 4 when Digi is doing well over DIN with external Clock but glitches out the moment ext mixer settings are enabled. I will report back once received a reply from Elektron about it.
__
Here a few cases with different settings where digitakt glitches out (and in comparison when it doesn’t)Summarizing
Test 1 shows set up with digitakt as master where only the playhead slightly lags behind with ext mixer settings enabled but tempo is stable. https://youtu.be/R7eOP2t_Ap0
> Test 2 is where the issue is: Digitakt synced via DIN with ext mixer settings enabled leads to massive bpm glitch out. https://youtu.be/Iymf8KGiG8s
Test 3 shows that the errors occurring in test 2 are resulting from the DIN midi port being overloaded at the digitakt as there is no bpm glitch out with ext mixer settings enabled and digi slaved to USB clock.
https://youtu.be/ASDBG-4E-Ts
> Test 4 shows its an issue with external mixer settings if they are enabled as the externally DIN slaved digitakt is stable if ext mixer settings is disabled in global settings. **
** https://youtu.be/lvLsPL_iPkQ
I hope this helps. Please let me know if you need further info and thank you loads for your time and goodwill.
Cheers, Niko
I use a UC4 with my digitakt mk1 going through a mioXM. Well mioXL at the moment and don’t notice any lag. It sounds a similar setup. I do have DT as master clock. Unsure that’s helpful but still…
Digi as master is definitely helpful and usable. See test 1… Digi as slave via din midi clock with ext mixer enabled is where it all falls apart at least for me
Just a random thought: Are you connected to a computer using Overbridge?
No not at all. All tests have been done without usb connection to a computer and over bridge disabled in digi options. I also think it appears like a feedback loop somewhere but with this minimal set up I used for testing that’s simply not possible. What I do believe now is that it has to do with digitakt (and other Elektron boxes for that matter) run with their own data language so all incoming midi is translated before processed inside the digitakt. Maybe there’s simply not enough CPU to process this vast amount of info or it’s efficienciently programmed. Maybe digi sets the volume levels for all patterns of a project simultaneously instead of having a dedicated master mixer that gets utilised instead with external mixer enabled, which would explain the bottle neck from a programming perspective.
I’m just now catching up with your progress. If I’m understanding correctly it seems like elektron support acknowledged the issue without proposing a solution so maybe there is no solution, it might be easier to accept that there is no solution than it is to continue.
Since someone else here said they aren’t having any problems with a non-current firmware, and we assume that means digitakt shouldn’t bog out under that midi data load, then you could back up your projects and then try dropping back down to 1.50 and start with a test project to see if there’s any change in the behavior. 1.50 is probably the lowest you could go without running into project related conflicts because that’s when machines were introduced on DT, below that I just wouldn’t trust that additional errors won’t occur in projects loaded from 1.51 because my understanding of the data structure of project file backups isn’t sufficient to say they’re completely retro-compatible.
Then the other and maybe the most reasonable thing you could try would be to have another different midi controller with cc control and someone else with another digitakt on the same current firmware version so that you could try both another midi controller with your current setup, then also try your midi controller with their digitakt and (if necessary) the second midi controller with their digitakt.
Doing that would definitely make it clear whether or not there’s a pattern emerging with the external mixer enabled on both causing a common issue on the current firmware. If the problem only occurs with your digitakt then something else might be going on and I don’t know if it’s got to do with your hardware or your projects or what.
If the results between 2 digitakts with the literal same physical midi controller are different, the next thing I’d probably do is load one of your projects that always has problems onto the other machine and test for the behavior to occur. If it does glitch out the second machine, then something in your project is causing it and I really can’t say what.
Due to the regularity of the issue and improvements based on configuration it doesn’t sound like corrupt data (to me), but I just don’t know.
If it does not glitch out the other machine, with the same firmware version, with the same project, with the same midi controller then I’d say that points directly at your digitakt and adds an extra layer of confusion.
At that point you could maybe factory reset your digitakt and then reload the firmware using sysex with DIN midi cables instead of a USB firmware update. I’m not sure why this helps but I’ve seen it work a few times, perhaps a sysex firmware update by process loads additional basic files that don’t usually need to be exchanged and are skipped by USB but that’s just me guessing at why it might help, I don’t know if that’s at all accurate.
So, if you wanted to try the sysex firmware load you would need to see if your audio interface has din ports and can act as a midi hub (that is, if you don’t already have a dedicated USB midi hub, in which case you could use that). Then you would follow the instructions on this page from the elektron website:
How to update your device via sysex transfer : Knowledge Base (Beta)
This step is really just to try and rule out a problem with not necessarily elektron’s firmware, but with the actual files on your machine containing the firmware.
It’s unlikely to yield results with your specific issue but if you want to be thorough and all the other stuff that I mentioned was randomly exactly or very close to what you experienced, then the wall you hit will be “is it really a problem with the hardware?” Because that would be hard to self-diagnose, so by hoping to eliminate any software type cause specific to your machine, the things within your control are testing a with previous firmware (not before 1.50 though) and reloading existing firmware with as much of a clean slate as you can get.
If you’ve arrived at this point and it’s only your machine that has the problem with all possible firmware variables tests and 2 midi controllers, after none of the other tests yielded any problems with the other machine, then I’d have no choice but to suspect something on your machine which was not the operating system.
So whether that’s some other base level software process, or a hardware issue, I really wouldn’t know. That goes probably beyond what I have the capability to puzzle out here, but it would shine a light on your machine as the culprit as opposed to digitakt in general or it’s relation to midi cc control or a faderfox.
Although in the event the second midi controller worked fine with your machine and it’s just the UC4 and only with your machine, not the other digitakt, there’s still a possibility that those could be in conflict in some unknown, unseen, untraceable manner.
This is why I say that it may be easier to assume that whatever elektron support said is meant to indicate this is an issue with no solution. I’m probably the worst person to say “accept that there’s no solution” to, because I’ll keep trying beyond the point of reason. Sometimes it works out for the best, and other times it just takes forever and nothing comes of it.
At this point my response has gotten rather long but that’s about all I can think to try, other than jumping straight to accepting that the behavior on your machine, with the external mixer enabled, is expected to act in such a way as what you initially described when stating the problem.
Thank you once again for all the suggestions. Will definitely try with another controller to see if it’s the faderfox by any means and will take your sysex related suggestions as a matter of last resort. In the meanwhile Elektron has replied to my videos which I will post below but in short, they are puzzled as well.
Will keep you posted with all and thank you for your suggestions, youve been of great help this far already, big time!
Here the Elektron support reply. Will keep you all in the loop.
Hi,
This is truly an interesting bug, and I will try to validate it as soon as possible, I just have to find the hardware to simulate your setup and midi signal flow.
I will also forward this to the developers.
I will look into if this exists on the Digitakt II as well.I will keep you posted.
Best regards,
No worries. If elektron can confirm and then acknowledge that it’s a bug then that would be the easiest, if not solution, then at least validation that there was no way you could influence the outcome by doing more.
It’s always possible you could find a workaround, but it’s going to be a matter of value when it comes down to this kind of cost to benefit ratio problem solving. In this case, it may be more truly stated as time to benefit rather than cost.
Anyway, I can’t say that we accomplished much here but if it at least helped you demonstrate the issue to them in a more articulate manner, then hopefully it at least saved you both some time in conveying the issue and then in having the issue recognized or acknowledged.
So at least there’s that 