Why is this simple Core envelope not working? (Based on ReaktorTutorials guide)

Thanks guys and thanks ColB for the long explanation. Makes perfect sense. I do notice the click is lessened by syncing the oscillator to gate and removing the delay at the start (so the attack phase syncs with the oscillator sync when triggered) but I think the most reasonable management is to just increase attack time. I will do some audio recording at some point of my guitars and drums and measure the exact attack times out of interest but right now no time for that. I will post back with any readings out of interest if/when I can get to it.

I am still learning so I ask questions and they won't always be good ones. All this synth stuff is still very new to me.

If there's anyone else out there learning, I'd strongly recommend Salamander's stuff at Reaktor Tutorials. Very comprehensive and he explains most things well enough for a complete novice to grasp. Worth the $10 /month for sure.

Now back to curve controls...

 

Okay so I added the curve controls, and it works wonderfully. Thanks again to all. Couldn't be happier with this.

I am realizing the click of a rapid attack is absolutely not a musical problem in a polyphonic drum/guitar synth design - the only problem is if the click is INCONSISTENT. ie. Sounding different on different hits randomly.

As ColB said regarding click randomness: "This gives the clicks an intermittent quality - some sounding louder, others barely audible, making the clicks more annoying and less musical... You can try to fix this a bit by resetting the phase of the oscillator every time a note is triggered, but this can also create problems if the oscillator was already audible (often the case in a monophonic context) because the phase reset causes a discontinuity in the waveform creating - whaddayaknow - a click "

I do not have a problem in any monophonic situation with for example drum synthesis. But I am still not sure of the exact best fix. I've tried using a synced oscillator with the sync linked to the gate. I can't tell 100% if this is working exactly as it should be. Should it be?



Either way, this solution won't really work once I start feeding modal or sine banks as they don't come with sync functions. I'd have to build that in somehow.

Additionally, since the delay portion of the envelope (at the start) is set to a minimum of 0.001, should the gate going into the sync be put through a delay of 0.001? Tried this and couldn't appreciate any difference either way.

Attached an ensemble of it as an ensemble.

As a point of interest, I tried building the envelope functions with the Envelope Toolkit suggested by sellotape. Major problem with that. It comes with prebuilt curve controls, which is nice, but they are limited to an arbitrary (-10) to (+10) range which can only give the weakest of exponential curves. No use in this situation.

This attached envelope as designed by Salamander is capable of the most aggressive curves, which is far more useful.

Just wanna get this click situation resolved to the best I can and then on to bigger things.

 

For a mono synth, one option is to duplicate the oscillator section, and flip flop between two oscillator section. This way you can safely reset the oscillator phase without a reset click.
EDIT: Actually, this not a good approach. It's only possible to achieve by introducing more workarounds that cause their own problems.
Sorry about that

 

Had a look at your ensemble.
If you set a fairly long attack - should be no click - with a high sustain level and a longish release, then play a bunch on fast notes, you get lots of clicks. This is because you are syncing the oscillator to the gate. remove the sync and everything is fine.
To me it makes more sense to accept the click on fast attack rather than try to fix it and introduce a click on slow envelope sounds where it is definitely more of a problem!

 

Yeah colB. I was also thinking if I use this in conjunction with the modal bank (which I'm planning) it should always be "synced" because the modal bank only starts its filters upon "gate" input which solves that issue. So not worried about that.

Unfortunately I've identified another glitchy behavior of Salamander's core envelope design. If a key is held down for around 6-8 seconds, the envelope seems to "let go" and return to a value of "1" (wide open).

This is demonstrated with this simple ensemble, where if you press a key and hold it, after 6-8 seconds, you will be get an abrupt onset of a full level sine wave (turn down speakers). The sine wave will continue until you let go of the key press.



This is strange behavior. I've looked at it and looked at it and can't figure out where this is coming from. Simple demo ensemble attached.

Anyone have any thoughts/solutions?

Designing is tricky business!

 

The reason therfor is the power function used in this structure. As the module info says "x must be >0". You can simply add clipper that clips every incoming value below zero and this should be fixed. Another solution would be to keep the calulation linear and only shape the output of the stage with a parapol shaper. This has the nice benefit that the individual stage times dont get effected by the shaping so they always have the same time no matter what shape you select.

 

It is the power function that is causing the problem, but not the x>0 condition. The problem is that the curve settings are so extreme. With the curve set to crazy values (here its ~177), the exp module in the power function overloads, but instead of clipping, wraps internally and starts generating massive negative numbers.

@mike_jm
Best option IMO is to modify the envelope so the settings are not so extreme. Alternatively min-clip the output of the power module to zero - although you could still end up with some annoying 'inf' outputs if you do it this way.

If the power function is overloading, but you are close, it's possible to massage things to work at the expense of some precision, but in this case, the numbers are extreme, so no point. e.g. with 'curve' set to 177, when the input value is 0.5 the output of the power function should be 4.26E-54 that's insanely tiny - the exp function falls over way sooner than that!
It tries to throw an inf at you (with input somewhere between -80 and -81, but a bit beyond that it wraps the floating point representation and gives massive negative numbers.

I'm really not sure why the curve settings need to be anything like as extreme is this though - just doesn't make sense. An exponential decay with an extreme curve setting might as well be a decay with a non-extreme curve setting and a shorter decay time...

What would be a useful modification is to put a curve on the control values. This is essential IMO for a good envelope.
The time and curve knobs should all be 0..1, then raise them to a power. e.g. square them twice with two multiplication modules (or cube them - whatever works best). Then scale the result to the maximum value you want. This way e.g. the attack control gives much more precise control over short attack times. Same goes for curve settings. There is usually some subset of the range of settings that you need more precise control over because that's where most of the wholesome goodness is.
You can take this further and split the control input into sections, mapping and scaling each one differently, but a simple power curve, then scale is usually enough.

Here is attack: input 0..1, curve applied, then the adder scales to 0..2. Turn of the value display on the knob, and add a numeric, then feed the numeric with the curve mapped scaled value!

 

Thanks ColB for pinning that down. I can see what you mean using the debug tool.

From what I can see, the x^y module will gradually decline to around 10^-38 or so, then it passes zero and goes negative for a bit (down to neg infinity), then shortly later, it cycles back up to an enormous positive numbers (up to positive infinity), and then in continues cycling back and forth between these two extremes as long as you hold a note down. When it goes back positive is when it makes the BEEEP.

I realize what you're saying about having more realistic/practical synth settings. You're entirely correct, and knowing what the problem is helps so I can avoid it. Still despite that there are three reasons I want to fix this more fundamentally:

1) Practical - My computer keyboard is right in front of my music keyboard so sometimes I lean on my music keyboard. If I lean into the keyboard right now with a patch running I get a blast sooner or later when this thing overloads.
2) Creative - There are times I might want even moderate curve settings with a sustain pedal held down for a while, and I can't have this thing risk overloading due to the sustain pedal.
3) Principle - I don't like things that just don't work properly - there has to be a fix.

In theory, there is one good way I can think to fix it (though I don't know how to actually do it). The ideal solution would be if I can build some sort of router that stops outputting the ~exp2 function once it reaches zero, and doesn't "reset" to be able transmit a new signal from ~exp2 until a new gate trigger comes through.

ie. To illustrate the idea, I can build this:



The idea is once ~exp2 hits zero or below, it should no longer be passed through the signal chain anymore, as it's now garbage data.

But the problem is currently, eventually after going negative, ~exp2 goes back to the positive zone and is let back through the router again based on the compare function. I would need a way to make the router "permanent" once [ 0 > ~exp2], and only "reset" to reroute otherwise once a new gate input (new note) comes in.

Is there any tool in Reaktor that can remember when an event has happened (ie. when ~exp2 hits zero) and store this somehow permanently for use until the next gate trigger (and then have it get wiped clean by the new trigger)? I feel like the read/write modules may have something to do with this but I don't know ...

I know this may seem silly but to me this is very important so I still appreciate all feedback or ideas!

Any thoughts?

 

Move the clipping before the '~exp2' and change the minimum value to -127 to avoid the back flip to positive values.

 

yes, clipping before the exp will work.
For me the only 'correct' solution is to use input values that don't push the system out of range. Bring the maximum 'curve' setting down until it doesn't cause an overflow. Pretty simple really - any value above that is going to cause clipping to happen if you use a clipping solution. Limiting to a valid curve range will ensure that all control settings actually work as intended.

Its pretty easy to setup a test for the pow or the exp module to find the limit, then choose a maximum curve value below that limit. BOOM

EDIT: seems maximum save upper limit for curve is 22.5 (so 22 should be a good bet), but it depends on how low you min clip the x input.

 

Here's a link to a post I made years ago about how to extend the limit of the exp function (reduced precision)

And I've attached an example ens.

With some exp scaling, the input x can be clipped to 1e-07 instead of 1e-05, and the curve range can still extend to a maximum of around 85 instead of 22. (EDIT: these range values are wrong see below)

The trick I suppose is to balance reduced precision against wider input range. I think you could extend it much further than this without the loss of precision having any audible effect on quality. You still need to thoroughly test the input range and ensure that there is never an out of bounds situation. Probably best to use a ramp osc on the x input to avoid missing some corner case, rather than just randomly testing a few values with a knob. Then pick min x and max curve limits higher and lower respectively than the tested extremes to be safe.

EDIT: lol, just checked with a clipper on the x input instead of just using the compare/route from the original OP version, and the ranges I've been posted are wrong due to using knobs for testing.
The real ranges for a minimum x input of 1e-05 are:
no scaling : x = 1e-05, curve 1..~7.66 !
scaling : x = 1e-05, curve 1..~30.7
I uploaded the fixed test as well

 

Thanks guys as always. You guys are fantastic. All good solutions. For pure simplicity and "can't fail" operation, I've put the clipper before the exp2 function to -127 and it can't blast me anymore. Though I understand the value of the scaling as you've discussed ColB as another way of addressing this.

Thanks again.

 

I would say you had two distinct problems.
1 Protecting ears and equippment
2 incorrect operation of envelope

Clipping before the exp doesn't fix the problem of incorrect operation - the exp scaling does.
Clipping before the exp only protects you from errors caused by the envelope. It's good practice to put a clipper on the main ensemble or instrument output, particularly during development - this protects ears and equipment from any bug in any component. You can also set up a lamp with a peak detector, or an audio shutoff with a warning message to tell you if there has been an output clip that wasn't immediately obvious aurally.