Hello,
I am working on an ADAU1466 SigmaStudio project for a hexaphonic guitar.
My goal is to create a banjo-like decay characteristic, where the note decays much faster than a normal guitar while preserving the natural attack.
I am using a GainEnvelope block, but I have a problem:
The GainEnvelope starts correctly on the first pick attack. However, once triggered, it always completes its programmed cycle and cannot be retriggered by a new pick attack while the string is still ringing.
For example:
Pick a string
Let it decay to approximately -20 dB
Pick the same string again
Ideally, the second pick attack should restart the GainEnvelope from the beginning. Instead, the new note is affected by the remaining state of the previous envelope cycle, causing the second note to sound quieter than intended.
My question is:
What is the recommended SigmaStudio method for detecting every new guitar pick attack, including attacks that occur while the previous note is still sounding?
This is especially important for fast playing, where multiple notes may be picked before the previous note has fully decayed. The final goal is not note-on detection from silence, but reliable attack detection on an already ringing guitar string.
Is there a dedicated SigmaStudio block for this purpose, or is a custom transient/attack detector the recommended approach?
The platform is ADAU1466 running in SigmaStudio without an external MCU.
Any ADAU1466 / SigmaStudio specific suggestions would be greatly appreciated.
Thank you.
BanjoDSP - Moved from SigmaDSP Processors & SigmaStudio Dev. Tool to Processors & DSP. Post date updated from Tuesday, June 2, 2026 4:04 PM UTC to Tuesday, June 23, 2026 5:41 PM UTC to reflect the move.
Hello,
You've thought of an interesting and fun application! To my knowledge there's no one block for this, yet SigmaStudio allows us to build complex functions with its basic blocks. The project shown and attached below appears to work with its built-in test signal -- you'll need to test and perfect it with a guitar input.

The Peak Envelope1 block finds the level of the incoming signal. Next, the coefficient table inside filter FIR1 has been set up as a Hamming differentiator (Lyons, Understanding Digital Signal Processing, Third Edition, Section 7.1.2). A rising signal produces a positive output, a decaying level causes its output to go negative. Striking a guitar string produces a peak higher than the the level at the A input of comparator ABCD1, causing its output to go high. This triggers OneShotR1, which produces a 1 millisecond pulse (set by Timer1). SlewVol2 is set for a quick rise time and a slower fall time. Adjust its fall setting for the desired "banjo" decay. You'll find a table of rise and fall times corresponding to these settings at this link.
The test signal has adjustable "strumming" rate and tone pitch. It works over a reasonable range of these as well as with a range of input level. Of course I'm curious about the results you get with a real-world input -- let us know!
Best regards,
Bob
Dear Bob,
Thank you very much for your professional help! I really appreciate it.
I will definitely report back with the results.
Please be patient with me, as this will probably take several weeks, or even a few months, before I can thoroughly test and evaluate everything.
Hi Bob,
Thank you again for creating and sharing this project. I think I have identified the main reason why the effect behaves differently with a real guitar signal than with the built-in test source.
The main issue is not simply noise. What I hear is a repeated re-triggering during the natural decay of a guitar note, which causes the volume to repeatedly open up again, creating a "pumping" or "reappearing" decay instead of a smooth banjo-like fade.
After investigating the guitar signal, I realized that the amplitude envelope of a plucked string is often not a smooth exponential decay. The signal level can rise and fall multiple times during the note's sustain. I believe there are at least two physical reasons for this:
The amount of this amplitude fluctuation is not constant. It varies significantly from string to string and even from fret to fret on the same string. Some notes behave almost perfectly, while others show strong envelope fluctuations.
Because your detector is based on:
Peak Envelope -> Differentiator -> Comparator -> OneShot
I suspect that these natural envelope increases are interpreted as new attacks, causing repeated triggering of the OneShot and reopening of the Slew Volume stage.
So far I only had time for a quick test and confirmation that the project works with a real guitar signal. I have not yet had enough time to systematically experiment with settings.
Some ideas we discussed for future testing are:
Another idea that came up is using two envelopes instead of a differentiator:
Fast Envelope - Slow Envelope
which appears similar to the "Differential Envelope Technology" used in products such as the SPL Transient Designer. The idea is that a true attack would produce a large difference between the fast and slow envelopes, while slower amplitude fluctuations during sustain might be ignored.
Since I am not a DSP expert, I should mention that this entire project was built with the help of ChatGPT. Most of my previous SigmaStudio work has focused on guitar tone shaping, EQs, preset switching, and multi-channel processing rather than transient detection.
I will continue testing and report my findings when I have more time to experiment. In the meantime, I would be very interested in hearing your thoughts on the envelope fluctuation issue and whether you have any suggestions for improving the attack detector or making it less sensitive to these natural sustain variations.
Thank you again for your help and for sharing the project.
Hello,
The issue you found reminds me of a '50s (?) song, Johnny B. Goode -- he could "play a guitar just like ringing a bell." Bells are known for rhythmic waves of harmonics with varying amplitudes and phases. To synthesize a bell sound you needed balanced modulators, which weren't cheap back in the 70s. In the DSP world, a multiplier does it. DSPs are multiply-and-add machines, so the chip you're working with has literally thousands of them! I grew up with vacuum tubes, so what little I know about DSP is from reading a few books and playing with SigmaStudio. You'll have fun doing the same.
It's no surprise that a real-world input would cause issues, although I didn't expect this one. I added modulation to my simulated "guitar" although having no idea of how much modulation (or, "ripple") in the guitar signal would be present:

Then I made the incoming signal increasingly "difficult" for the project to handle until it just couldn't. In the scope traces that follow, the top trace is the output at PeakEnv1, the bottom is the project's audio output.

This first example is with no modulation and a strum rate of 10 Hz. The stairstep in the decay is from the 10mS "hold" setting of PeakEnv1. We set this to reject ripple from individual cycles of the input waveform -- thus we need more hold when lower audio frequencies are present. Ten mS is enough to cover a 50 Hz input, which has a period of 20 mS and thus a time of 10 mS between peaks (all SigmaStudio level detectors are full-wave; in DSP this is merely "absolute value"). You can make this shorter if 50 Hz is never present, or longer for a holdoff against multiple triggering, as you have suggested.

This one is with 5 Hz, -10dB (roughly 30%) modulation, with a low 1 Hz strum rate. It works fine here.

It gets difficult when the modulation rate and the strum rate are nearly equal -- here, 10 Hz and 8 Hz respectively. Also the modulation has been increased to -6 dB (50%). The project cannot make sense of this chaos. It appears that banjo picking is often even faster, so it mayl be tough to separate the modulation from the picking.
Presently, I don't know exactly how to fix this, yet it's something we can work on together. You said your DSP experience is limited, but if you have analog EE experience this is quite helpful. SigmaStudio is great for building analog-like circuits and you won't burn your fingers on a soldering iron! There’s a few guitar enthusiasts on EZ who might jump in and help.
Edit: By the way, you can retrigger the Envelope block by interrupting its control input (that is, setting it to zero) for just one sample interval. Yet, presently this isn't useful since we're having trouble with the basic idea.
Best regards,
Bob
Thank you for your new ideas!
I really like your simulations, and in my opinion the second version is the closest to the decay of a real guitar note. However, I still haven't been able to fully characterize the amount of amplitude modulation. Based on my measurements so far, it seems to vary not only from string to string, but even from fret to fret.
Your simulation gave me a new idea: generating the trigger signal from a separate high-frequency band.
The reason I think this could be promising is that the highest harmonics seem to decay much faster than the lower frequency components, and they also appear to exhibit much less amplitude modulation during the decay. My idea is to generate the trigger from this high-frequency band, taken directly from the original full-band signal before any EQ processing. That way, the trigger would mainly respond to the initial attack while being much less affected by the later amplitude fluctuations that occur during the note's decay.
So far I've only had the opportunity to think about this idea theoretically. Within the next few weeks I'll finally have time to build and test it properly, and I'll let you know the results.
Best regards,
Nicholas
Hi Bob,
I finally had some time to really dig into the project. Based on what I've learned while working with it, I honestly think your solution works extremely well!
It actually didn't take very long to get the basic idea working. After just a few hours I found that most of the retriggering problems could be eliminated by carefully adjusting a few parameters. My guess is that the random retriggers were caused by the uneven decay of a real guitar string. During the decay, the system occasionally interpreted changes in the envelope as a new attack, so the note would suddenly jump back to full volume.
The two settings that helped the most were the ZeroComp bit value and the OneShotRise timer. After that I fine-tuned the Peak Envelope Hold and Gain values.
Once I had eliminated the retriggers, I noticed another issue: sometimes very soft picking wouldn't trigger the effect. I also found that after a loud pick, a softer but still intentional pick—or even several in a row—would sometimes fail to retrigger. Instead, the string would continue playing at whatever reduced level the Slew Volume was currently producing. So I kept experimenting with the Hold and Gain settings until I found a combination that solved both problems.
After that I tried every playing dynamic I could think of, from the lightest touch to very aggressive picking, and the trigger became completely reliable without unwanted retriggers. It even responds to the slightest touch on the string, not just normal picking.
It took me about one full day to optimize a single string for every possible playing situation, then another day to repeat the process for all six strings. (For me that's about 14 hours... if I start something, I tend to do it properly. )
Then I made a "mistake" during testing. While working on one string, I had disabled the pickups for the other strings. Everything looked perfect. But when I turned all the pickups back on and started playing chords, I suddenly got frequent retriggers again. It turned out that each pickup, although much quieter, still picks up the neighboring strings.
In the end I'm actually glad this happened because it showed that the main limitation wasn't your algorithm—it was pickup crosstalk.
The behavior makes sense. Different notes decay differently, both in level and over time, and occasionally the algorithm interprets those changes as a new attack. So I had to go back and adjust everything again. That took about another week, but eventually I managed to get the dynamic behavior working exactly the way I wanted on all six strings.
My priority was making sure every intentional pick would always trigger. I do still get the occasional retrigger, but only after a chord has almost completely decayed (with the fast banjo-style decay), when the strings are already extremely quiet. In practice this really isn't a problem. It's a fairly uncommon playing situation, and the retriggered notes are so quiet that they're hardly noticeable. In fact, accidental string noises during normal playing are usually more obvious than these occasional retriggers—and even professional players produce those kinds of noises.
One interesting thing I noticed at the end: throughout my testing I kept the Slew Volume release (decay) time fixed and eventually became curious about how short I could make it. As I reduced the decay time, the old problems gradually started coming back. Below a certain minimum value—which was slightly different for each string—soft picks stopped triggering reliably again, and harder picks sometimes produced immediate retriggers. I could improve things somewhat by fine-tuning the other parameters again, but eventually I reached a practical limit below which I couldn't shorten the decay any further. That's perfectly fine though, because I don't actually need it any shorter.
So in the end, getting the system to work well with chords required only a very small compromise. It might even be possible to optimize it a little further, but from a practical playing perspective I'm completely satisfied with it now.
The system really works. And if I decide to redesign my pickups in the future to reduce crosstalk, I think the results could be even better, because at the beginning—before crosstalk became part of the picture—I wasn't seeing these problems at all.
I've attached a WAV recording as well. For this recording I intentionally set the release (decay) time a little shorter than what I'd normally use, just to push the system a bit. Even with this setting, false retriggers are still very rare.
Thanks again for all your help! I really appreciate the time you spent putting this project together.