Random horrible repeating noise when changing patterns remotely

Elektron Gear Digitone/Digitone Keys
#21

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

#22

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
#23

The manual says;

Screenshot 2023-07-22 at 13.05.27
Screenshot 2023-07-22 at 13.05.271192×136 8.11 KB

1 Like
#24

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…

#25

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

#26

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.

#27

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…

DigiTest
DigiTest3192×2501 1.81 MB

3 Likes
#28

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!

#29

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.

#30

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
#31

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.

#32

Did you test this (above experiment)? Do you think that’s normal behavior of a synth? I have had many synths over the years and experimented and used extreme delays and familiar how feedback loop can get out of control BUT this is something else IMO.

Obviously one strange thing is that you can get this explosion from a pattern which has delay level 0, WID & FDBK 100% which itself plays without delay at all. Explosion comes when you start next one with normal settinngs. Do you think DN is designed to behave like this?

#33

well if it’s in the manual, it’s by design, at least that’s what it means to me.

hell yeah I’ve tested it, it’s one of my favorite effects, and yeah it can be very extreme, that’s why I’ve moved it to GLOBAL so I know for a fact I don’t leave it in the crazy zone.

anyway, I really don’t try to argue with you about product design, just stating that it is what it is and it’s dangerous thing… sorry if you feel like I’m not helping you by sharing the concern, it’s just that I discovered this almost as soon as I got the DN so it’s nothing new to me and I’m VERY aware of the feedback and filter width.

I even made a meme very recently about it :slight_smile:

so again, sorry for not being as concerned or angry about it as you, it’s really that I’m very aware of it and that’s all…

#34

Well, I am not angry or especially beggin support for my concern. I just see this as “malfunction”, not as specially designed feature. And I am talking mainly about the issue of delay stuff (in this case WID and FDBK) messing up next pattern even if you press stop and there’s time between. Something (delay buffer?) is full of s***t when trigger a new pattern and that’s odd.

1 Like
#35

I think every elektron machine does it, so maybe opening a ticket is the only way to raise official concern, but in the meantime you know what’s the issue so you can treat it as a limitation and work around it

1 Like
#36

It mostly seems like normal operation to me.

  • The delay volume control is the output level, not the input level - so adjusting it has no effect on the feedback generated in its buffer.

  • With feedback at 198, the delay buffer is being completely filled with feedback the entire time that pattern is playing, even if the volume is at 0 - which is probably why it sounds like a burst of random noise.

  • The buffer is not cleared during a pattern switch.
    So when you switch to another pattern that might set the delay volume to 100, all that feedback is released, and decays at the new feedback rate.

But it only seems to decay once you trigger a note in the new pattern, and it seems to boost the volume when that happens.
It’s only the last part which seems like it might be unintended - and could have been my settings when testing.

It should also be noted that hitting stop once does not stop/clear the delay/reverb buffers.
You can clear the buffers by double-tapping stop, rather than letting the feedback continue running.

2 Likes
#37

This makes sense. But one thing does not match: hitting two or more times stop does not help (clear fx buffers).

#38

I can’t reproduce that behavior here.
Double-tapping stop always clears the feedback.
It’s a double-tap though, not just pressing stop while it isn’t playing.

1 Like
#39

To be clear you could not reproduce my whole delay-issue or what I said about double-tap? I suspect the latter. I can make this explosion to happen with for example A01 (Imagine) and A02 (Dreams) patterns of factory project if I edit A01’s delay WID & FDBK 100% and VOL 0 and change from A01 to A02. (without double-tap, “normal” stop or pattern change on the fly)

After you clarified how to actually do double-tap now I can make it clear the feedback and it does work. Thanks!

…

One last thing about what’s being “normal” behavior of delay. I’d say that most synths do not behave like this. Delay is somehow protected from “overheating” or getting dangerously crazy. For example if I take my new Nord Stage 4 and put delay dry/wet and feedback to maximum for sure I’ll get a neverending delay but this does not raise volume or go crazy.

Well you’re right, warnings are there in the DN manual but this does not say that it’s wise or nice thing from developers to leave Elektrons like that. I did not consciously do that corrupted pattern (which played normally, because delay output was 0), it was probably “done” by some Midi CCs coming from other gear - I have tested many many things and MIDI can sometimes go routes that aren’t meant. So following Murphy’s law it’s basically possible to get this problem by accident if you mess with MIDI a lot. Then in bad case this one accident may be fatal to your audio equipment or to your hearing (being near loudspeakers, having in ear monitors etc.). This is why I wouldn’t downplay this issue no matter rare it is to get. Remember that I have had DN for three years and few weeks ago it justbevolved by accident. So to conclude: IMO Elektron
should fix this issue instead of just warning in small text on page XX

1 Like
#40

That’s great to hear!
A double-tap not stopping the feedback is what I couldn’t reproduce.

Many delays will not go above 100% in order to prevent things getting out of control.
There are creative uses for it, which I suppose is why Elektron boxes allow you to do that; but it can be dangerous.
I do wonder if there should maybe be a “lock” option in the menus to prevent it going above 100 accidentally.

But at least it seems like everything is working as intended rather than being a hardware fault, and we’ve figured out what is happening - even though it is undesired behavior.