What exactly do you mean with 30 seconds rule? Do you think it would help my issue which is rare - you can have everything running smoothly for hours and then it happens or not?
Never turn the unit off then back on without waiting 30 seconds before doing so. It’s in all Elektron manuals.
I believe the reverse is also true; never turn the unit on then off without waiting 30 seconds.
1 Like
Yesterday I had with Digi connected to Nord Stage with trad. Midi cables, no computer, usb or other gear. This was clear indicator of Digi malfunctioning.
Yeah what @d4ydream said. And yeah, for me it removed all unpredictable bugs i was having, that were happening hours into using the device. You could run your machine in test mode too (func + boot), to check for ram errors, but i feel like your device is fine and just needs good on/off cycles.
Regarding midi loopback crashes, just gotta make sure you are not crossing any beams. These usually result in imidiate crash however, so i dont think its what you are experiencing.
I had strange DN behavior when not powering off and on correctly when I first got it. They do not like fast off on and vice versa.
No issues in a long time as I knock on wood!
I’m pretty sure that’s how long food that fell on the floor can be eaten!
3 Likes
Sounds like it could be this bug:
Seems to be caused multiple arpeggiators plus sound-locks.
1 Like
Hi all and thanks for input so far!
As a original poster of the issue I’ve done some experiments to try to figure out what’s going on.
first it’s not soundlock or arpeggiator issue. Those patterns which (quite randomly) make this horrible noise do NOT use arpeggiator or locks.
second I’ve done those things users suggested - running test mode, everything seems to be fine, I’ve done factory reset and kept this 30 seconds rule of powering off/on. No help from these.
Here’s what I’ve found:
It’s quite rare and random - sometimes I can use Digi for a long time and nothing happens, sometimes it’s more frequent. But every time it occurs it comes when I change pattern and hit play. This noise come immediately after “play” and then resolves itself soon after. In other words I seems that once a pattern is there and works it don’t happen no matter how much you press play/stop. It needs this change of pattern to happen. About the pattern change: I normally use Mac or other synth (Nord) to change patterns via Prog Change message. Both setups have triggered this issue.
There’s some hint that it might be somehow related to Delay. To test this and trying to make it happen I put Digi to very low volume (to protect my hearing and my audio equipment) and recorded it audio. So I managed to catch few these crashes. As said in the beginning the volume of crash is infernal, it can really make damage. This is why this is so problematic. But in my test with very low general Digi volume I could hear this crash noise delaying and then fading and soon (about two bars) this “delay” is gone and pattern plays normally. Does this say anything to you? Here’s an example (be careful with the volume):
2 Likes
Doesn’t sound like it
What you present is something that it’s possible someone might sound-design the device to do (it has a limited output level no matter how random the happening that you didn’t plan for) so it’s not going to cause hearing loss because its character is unpleasant
The DN doesn’t do this when it’s on its own (midi wise) and the device is not ‘crashing’ as you suggested, it’s possibly not even a bug
is your nord sending CC messages to the DN thus resetting synth settings or delay time/levels such that there is a burst of activity ahead of (or around) the program change and its reception
if you are a professional musician relying on this it’s your responsibility to dig a bit deeper into what ALL your devices are doing potentially
so firstly try to find the offending patches and see if it repeats, look into whether the devices dispatching the program change is also dispatching its patch data (and whether this can be turned off)
if you are not expecting to specifically control detailed sound parameters of the dn remotely then disable the reception of cc/nrpn in the DN
also as suggested examine whether you have bi-directional midi in case this is making matters unpredictable - if you have midi out to in both ways for two devices then consider why ?
if it’s not repeatable or consistent for you it might be a timing thing or more likely it relates to particular patch combinations or midi
either way (and before you even create a support ticket) you need to methodically document settings and setup and provide details and ideally try varying the reception of CC on the DN … with great power comes some responsibility
only then can you start to consider if something is amiss with the DN, my money is more on that not being the case tbh no matter how irritating the sound because there are too many unknowns and external factors to say otherwise yet
Did you listen carefully my example? After this “noise delay” there’s a normal drum pattern which is barely hearable. To study this I did put Digi volume to VERY low to record this. Imagine this low level of drum pattern to be normal level on a gig and then suddenly comes this “horror delay”. For sure this can cause damage!
Believe me I’ve done quite a lot of study with this. And still continuing to do so. I’ve tried different setups and used Midi Monitor to see what is going on.
Based on my hours of testing I has become more and more clear that it’s Digitone. First I took out CCs, then bi-directional midi - just Nord Sending Prog change to Digi. (Yes this is verified many ways including Midi Monitor - Nord send just Prog Chg, I took out all CCs (and btw it cannot in principal send MIDI clock, just receive it).
Then when I found two patterns A and B that can provoke it more often than others I took out Nord from the equation. Manually cycling A and B with Digi it does it - so there it is. No external MIDI involved in this problem.
I think I’ve done my part here and I am grateful to others here on the forum too. And I am also going forward with Elektron support.
with respect you only provided any pertinent details after i mentioned there wasn’t much to work with
if you have two DN patterns which provoke an issue, then you can share reductions of them here so others can comment on why this may be happening
you can probably get a quicker outcome/solution/conclusion if you provide a repeatable scenario here - ideally a simplified version of what you have to minimise variables … even just try duplicating the patterns and see if it happens on a duplicate project or a duplicate pair of patterns
examine what is different between the patterns, take delay out of teh equation in both patterns and see if the noise burst repeats - then you are getting closer and closer to teh truth - by sharing it here you may get confirmation your gear is erratic or consistent with others
basically you have to help yourself to get the solution quickest - vague leading conclusions of “crashing” takes the discussion off into power-up hygiene and so on - only now have we established that it can happen standalone, that saves people thinking about other stuff … i.e. being methodical, and communicating what you know … whether here or with support, nonetheless your opening ‘issue’ description (including the previous “crash” title) wouldn’t get you any meaningful answer, but instead results in wasted responses
we all want to know if there are bugs and you definitely want to know if there is a hardware issue with your device, you will get more useful (possibly corroborating) ‘ammo’ for your support case (and with how to present it) if you do the legwork here
like i said, there is always a bit of responsibility to make an effort to narrow things down … just as i suggested, to which you only then added useful qualification
hey, I’d love to help u test this, can you isolate the patterns into a project and share the project?
I can test this with program change from ableton with usb midi or from EC4 by direct midi, see if I can replicate the same thing.
1 Like
Of course I started this whole thing ”tabula rasa” and had no idea what’s going on. Shouldn’t this forum be a place to check answers without first studying and testing for hours? I was hoping that someone might recognize this problem and then perhaps provide something to help. And people did that - well not the ”solution” but valuable information anyway.
Crash”, ”bug”, ”malfunctioning” … let’s see what this finaly is and how to correctly call it. Strange thing is that it emerged quite recently because I have had Digitone over three years. This was the main reason to believe that perhaps was somethig broken on a hardware. This is still a possibilty.
But anyway I keep isolating this and perhaps provide a test project soon…
For sure, we all have an interest in isolating a potentially horrible issue if it’s a weird bug that can wreck a moment and you have a vested interest in seeing if it’s hardware and we all potentially learn from that going forward if it is … describing it loosely is fine if you ask for areas to investigate, i’m afraid the ‘crash’ narrative took the responses in the wrong direction including one echo 2 above
there may be a horrible bug that takes some teasing out, but we need to get much closer to it
definitely create a backup of your issue project in case you need to refer back to it with Elektron eventually
the fact that your issue is happening in a particular moment (pattern change) starts to narrow down possibilities (like random board malfunctions etc) … the fact it’s recent in nature may point to a firmware related issue that you have seen that others haven’t … yet ? etc. etc
having the ability to cross-reference against others will help but may not be conclusive if the issue is timing related … taking the delay out of the equation may help direct attention narrower
likewise, you appear to suggest that there’s a pause between patterns (i.e. the need to press play)
see if the issue manifests when you press double stop on the first pattern as opposed to just stop etc
sharing a simplified version of what you have which gives the same outcome would be best imo
i would urge you to only use the DN if possible, disconnect from everything, including USB if the issue is indeed present standalone - if it needs a secondary device sending a prg.ch message then add details about how this is performed (is it sending bank messages, is it sending anything else etc, is it sent before you press play whilst the device is stopped ) … such a use case is not strange, but it will be uncommon amongst many users imho
also try muting tracks on the DN to see if it still does this, or even temporarily rotating patterns to see if the sequence is part of the ‘triggering’ issue
i’d look very carefully at what the delay is looking like … it’s almost like a hidden delay buffer is running wild and is being re-exposed when a delay time is extended … i have used one or two delays over the years which could exhibit this kind of buffer ‘cache’ issue - this takes it more into bug territory, but you can perhaps rule out delay related artefacts by removing FX from the picture by disabling them from the pattern clones i think you should re-test on - keep the original offending patterns safe somewhere
Im pretty sure ive created these sounds on demand before. they happen when certain criteria are met within the sound patch. And they are usually same unreasonable loudness like the one you shared. I havent tried program changes while experimenting with those though, so i find it strange that u only hear this after a program change.
I can walk you through how to make these kinds of sound appear naturally, so u could check the presets that you are using in case any of them already do something similar, if you want.
I think it might be related to how “inaudible” operators and carriers are handled, so more or less a bug.
EDIT: originally i assumed that your unit also crashed, thus thinking its related to power-cycle.
Ok…
I think I’ve found a cause for all this or at least I certainly hope so.
These low volume audio-recordings actually led me to think this is probably delay-issue (in normal volume you could only get a heart attack when you suddenly had it)…
I have about 40 patterns in my gig setup and I found ONE which for some reason had corrupted delay parameters and specially Stereo Width and Feedback full 100% On the other hand it had delay volume 0. (check picture) So basically pattern itself played normally (no delay). So the crash probably happened (not every time but sometimes) with next pattern with normal delay parameters. So messed up delay affected start of any pattern which I took after it. And there was stop in the middle.
Now when I realized this I could (and you can too) test it with practically any two patterns:
Take pattern A with normal Delay values
Take pattern B with WID 63 (full) and FDBK 198 (full)
Change between those and put volume very low. At least I get quite easily this terrible explosion. Digi should definately not do this.
Why didn’t I get this idea sooner? It’s because we play with no fixed order of songs (patterns). So pattern which “exploded” was the one after this corrupt one which itself played normally.
Somebody wiser than me can perhaps explain what’s left in Digis memory after this corrupted pattern. Delay buffer somehow allready full. Remember that you heard nothing when you played this corrupted pattern and then also hit stop and had a break between those two…
3 Likes
I’ve never encountered such abrupt noise but I do remember being annoyed by sudden delay/reverb changes on pattern change or even when creating new ones, so I set them to be global and there’s no way I don’t return the feedback to something normal by the end of the day, of course it’s up to you how you set them up but consider making it global and keeping in mind that you adjust them by taste on pattern change… the chance of locking the delay on 200% feedback would be extremely low.
glad to hear it’s not a faulty DN though!
Thats way more logical of a solution that i thought. Great job. If you wish to avoid this issue alltogether you can use Global FX in the settings like @alechko mentioned.
It would be nice for it not to happen though. Smooth FX parameter interpolation after program change would be a great option to have. I find it too abrupt even if my dials are not set to extreme values, thus i mostly leave it at global.
If we hope (!) this is now solved then question remains that is DN functioning correctly and reason is all mine (one corrupted pattern)? In my case this probably caused us one broken L’Acoustics speaker worthy of many many times DN. I don’t wanna think how much this has done harm to my hearing.
Personally I’d say this is clearly something that DN should not do!. If you test it (again with LOW volume!) you’ll easily see how horrible this noise is. Of course I’ll report these latest findings to Elektron.
1 Like
you say that but that’s something the Digitone is doing and designed to do, if you read the manual:
13.3.4 FDBK
Feedback Gain sets the amount of delay output signal to feed back into the input of the delay. With high- er parameter settings, infinite and swelling delays are possible. Please be aware that high feedback can lead to a very loud signal. (0–198)
so yeah you can definitely blow some speakers but that’s no DN fault… the warning is in the manual…
why is it doing it? well, if you lower the volume to ~1, max feedback and narrow filter ~1 width can give you cool effects, so that’s why the feedback, but if you have volume and broad filter then yeah, speakers and ears can blow quickly.