simple decay control

[tester]

I'm looking for simple decay solution, controlled by manual trigger (i.e. a way of making "dong" sounds with fade/release from max to zero). The decay module in SM toolbox seems to not react to typical triggers in order to activate/reactivate the fading. What I'm missing?

Another thing - would look for non-linear fading envelope plus long fading times (like 30-300 seconds), but I guess I can do that using some graph curves present on the forum, converted to arrays and triggered with counter via dezipper. But I'm looking rather for simple and effective solutions, with no complexity inside and no (known) issues.

[trogluddite]

It is possible to get the schematic that you posted working - there are two things to fix...

1) The envelope will need the "Trigger" property ticking to work with mono/mono4 signals - by default it is only in "automatic mode" for triggering only by messages from the poly voice manager.

2) Green boolean direct into stream boolean doesn't work...
There is a fundamental inconsistency in the way that numbers/bools work between green and float - leading to just the kind of unexpected results as you have found.
You will already have seen how the green parts will freely convert between float, integer and boolean data types. In green, a boolean false = zero, and boolean true = one. When converting from float/integer, any non-zero value will convert to true.
When these green values are connected to a code/assembly box, however, all those data types are automatically turned into float format - so inside the code, a green bool true -> float one, exactly what you would find if you plugged on into a normal "streamin".
However Stream boolean is not zero and one - the "false" value has all 32bits turned off (still zero), but "true" has all 32bits turned on - which is not a real number (hence the special connector type). This is handy in code, because bitmasks are used a hell of a lot for any kind of switching and decision making - being able to pass bitmasks directly between modules saves some CPU compared to checking for the value 1 all the time.
Connecting a green bool to stream leaves the expected bitmask incomplete, badly interfering with any bitwise "&" operations inside the code.

Fortunately this is also easily overcome - you can convert the green bool into s stream bool with this short code...

Code: Select all

streamin GreenBool;
streamboolout Out;
Out = (GreenBool != 0);  //Non-zero to true bitmask.

Now, having said all that - a custom envelope code may still be a better solution. The stock decay is strictly linear, and overcomplex (because of parts required for poly). All we need here is a way to set a value of one when triggered, and a way to iteratively make that number smaller. Here's a nice simple exponential decay...

Code: Select all

streamin Trigger;  //Green bool will work here
streamin Factor;  //Decay control (0 ... 1) = (short ... long)
streamout Envelope;

float OldTrigger=0;  float Small=1e-020;

// Iterate
Envelope = Envelope * Factor;  //Decay
Envelope = Envelope & (Envelope>Small); //Kill de-normals

// Set to one on leading edge of trigger pulse
Envelope = Envelope + (1-Envelope) & (Trigger>OldTrigger);
OldTrigger = Trigger;

The decay control will need some scaling in green, as it is simply a feedback control, so you'll be needing number closely approaching one for practical decay lengths.

[tester]

1) The envelope will need the "Trigger" property ticking to work with mono/mono4 signals - by default it is only in "automatic mode" for triggering only by messages from the poly voice manager.

I'm still lost? "Trigger property ticking" ? Where and what to change?

I tried second example, but I'm afraid that I don't follow it yet. "Factor" values below 1 are soundless, and =1 just produce continuous (or just verly slow fading) sound.

p.s.: Generally I would need something, that allows to retrig the fade from 1 down - during ongoing fading too.

Help

[trogluddite]

'm still lost? "Trigger property ticking" ? Where and what to change?

You will need to click the little "P" symbol at the bottom right of the module to open the properties, then check the appropriate box (will be labelled either "Trigger" or "Gate").

I tried second example, but I'm afraid that I don't follow it yet. "Factor" values below 1 are soundless, and =1 just produce continuous (or just verly slow fading) sound.

p.s.: Generally I would need something, that allows to retrig the fade from 1 down - during ongoing fading too

This one will retrigger at any point during the decay - but as I hinted before, you will need a "Factor" very close to 1 - the scaling happens 44100 times a second, so even a ratio of 0.9 will decay to nothing in a fraction of a second.
I have used before somewhere a little module for scaling the ratio from a 0-1 knob to give meaningful time - I'll see if I can find it for you and post it up, it will make things much moe manageable.

[tester]

Ah - my english failed.

[cyto]

You can use this formula for finding the appropriate factor:

(endValue/beginValue)^(1/samples)

if you are always going to be decaying from 1, than obviously it is endValue^(1/samples).

In trog's above example, the endValue is 1e-020, so a one second decay at 44100kHZ, would need a factor of .9989562888. (or 1e-020^(1/44100)). Hope that helps.

-cyto

[trogluddite]

Ah - my english failed.

It is phenomenally more successful than my zero knowledge of Polish!

(endValue/beginValue)^(1/samples)

Thankyou Martin, I had a feeling it wasn't anything too complicated.

I also found the scaler from the old schematic that I used - very similar power function, but I think this one was scaled for a different end value. My end value of 1e-20 in the code is just an arbitrary very small number to eliminate de-normals - it is way below the threshold of hearing, so the "audible" part of the envelope may seem a bit short when calculating to that end point. The equation used in my schematic is...

e ^ ( (-1000 / SampleRate ) / MilliSeconds)
...where e is Euler's number (about 2.71828).

That seems to give a fairly natural feel to the scale of the knob. As an exponential decay, it's kind of hard to say what the most appropriate end point would be anyway - but experimenting with that equation, I found that a decay of around 20-30sec is the maximum possible before you reach "saturation" of the float number (resulting in no decay).
However that could easily be extended by hopping the code - the decay time would multiply linearly with the hopping factor, so decay times of hours could easily be achieved.

The schematic with that scaler module in is this Complex Integrator. (module "exp") - the schematic is a kind of combination sin/cos oscillator (quadrature) and envelope, all in one.

[cyto]

Thankyou Martin, I had a feeling it wasn't anything too complicated.

I also found the scaler from the old schematic that I used - very similar power function, but I think this one was scaled for a different end value. My end value of 1e-20 in the code is just an arbitrary very small number to eliminate de-normals - it is way below the threshold of hearing, so the "audible" part of the envelope may seem a bit short when calculating to that end point. The equation used in my schematic is...

e ^ ( (-1000 / SampleRate ) / MilliSeconds)
...where e is Euler's number (about 2.71828).

He he. I know there are a lot of "Martins" on this board, but I am not one of them Though, I understand the confusion, because I (umm) borrow a lot of martinvicanek's work. Regarding the Euler approach: I have used this myself in the past for certain exponential envelopes but I believe that to be fully workable, you need to incorporate a "feedback arm" into the mix. Generally, I have used the coefficient 2PI*normFrequency (which involves a intermediate calculation to put the time period into terms of Hertz) and then have used the transfer function out=in(1-coeff)+out(coeff) where in is the starting value (one in this case). (This is from memory, BTW, have not tested - i may have gotten the mults mixed up). In that case, you're essentially using a simple LPF to achieve the envelope. I think in tester's case, where you just need a simple exponential decay, this may be overkill, but there are certainly cases where you are moving between different values where this may be more appropriate. I guess it all depends on the situation.

-cyto (Brad)

[tester]

I just want to make an approximate simulator of unusual instrument made of bronze alloys (bowl) that fades veeeery slowly after being hit (usually >30 seconds). For example one of my own units (2kg, c.a. 30cm diameter) fades for about 5 minutes after 1 hit . Not too cheap business anyway. Such instrument is "made" of several frequency bands, which fade differently however. What I need - is a manual control of that fading times. Fading type is between linear to a little bit indented (exp), so it would be good to have some control over that too (I guess - simple input with range "from/to" would be enough).

[trogluddite]

He he. I know there are a lot of "Martins" on this board, but I am not one of them

He he, sorry mate - I got myself all confused during the search for that schematic - it was an interesting journey via a many great schematics of yours and martin's (I blame it on all those imaginary numbers - they always made my head hurt!).

unusual instrument

I'd love to hear a sample of that! Just last week, I was watching a rather odd band (Volcano the bear) who use both conventional and home-made instruments. A section of their set was nothing more than each of the two performers hitting large metal "goblets" - and what a sound! One alone had a beautiful tone - but they played with the goblets in such a way to make constantly changing inter-modulations and beat frequencies from the two tones. The amount of control they had over this was amazing - I have never heard anything using detuned synth oscillators that comes close to that experience.
Such long sounds will ideally fit the use of code hopping - with the nice side effect of much lower CPU load too - so the ability to control many envelopes simultaneously. and to have a bit more complexity in the code for extra features (e.g. linear vs. exponential control etc.).
Near bed time now, but I have a few idea I may tinker with tomorrow...

[tester]

Regarding singing (not crystal which are different type of) bowls I go in three directions. Record live sessions, sample instruments and make soundspaces, or - process the pre-made soundspaces. The results: check this playlist for example (all except APR and some last from the bottom; but the APR is another interesting story for which I'd like to create proper filters in SM if possible instead of using offline CE processing) or visit bandcamp. Some are better with headphones.

[cyto]

hey tester,

see if this example is close to what you want...

flexibleDecay.osm

(5.89 KiB) Downloaded 85 times

You can change it's "profile" by inputting the midpoint value of the decay (in dBFS). Also you can enter in a hop value to save CPU resources (make sure you make the appropriate change to the code). You should be able to get extremely long decays, because this uses a 'counter' instead of a mult factor. Anyway, see if you like it

-cyto

[tester]

I check it tomorrow. Exhausted Too much SM thinking.
But from what you write - this should be it. Thanks.

[tester]

Okay, just tested, and this is it. But now things get a little bit more complicated. Cyto - could you add something to the code that would allow to set very short and smooth transition on retrig? Sizes in miliseconds (<5 ms I guess). The thing is - when envelope is retriggered, then transition tends to produce noticable "digital click". I'd like to make it more like analog soft hit, and I guess this is the direction (correct me if I'm wrong).

p.s.: when duplicated many times in the schematic (like 4x12) - SM becomes unstable and crashes often (I'm thinking to reach a target with c.a. 10x30 different envelopes) - to which part of the code could it be related? Is it possible to make some performance improvement by producing envelopes based on one main theme? (i.e. ratio based time lenght, so results of main code would be just scaled somehow?)

[cyto]

Okay, just tested, and this is it. But now things get a little bit more complicated. Cyto - could you add something to the code that would allow to set very short and smooth transition on retrig? Sizes in miliseconds (<5 ms I guess). The thing is - when envelope is retriggered, then transition tends to produce noticable "digital click". I'd like to make it more like analog soft hit, and I guess this is the direction (correct me if I'm wrong).

Okay, that's no problem. Here's a new version. It's exactly the same as the first except I just put a simple little lowpass filter on the output to smooth the transitions. Notice that I had to put it outside of the "hop" routine. Something like this wouldn't work inside the routine because of the inherent "jaggedness" of the "hopping". The good news, though, is you could conceivably make the hop value even larger because the LPF will smooth out any of the pronounced "steps" that the larger value would introduce. You can adjust the nominal transition time to your tastes.

flexibleDecayRev1.osm

(6.26 KiB) Downloaded 80 times

p.s.: when duplicated many times in the schematic (like 4x12) - SM becomes unstable and crashes often (I'm thinking to reach a target with c.a. 10x30 different envelopes) - to which part of the code could it be related? Is it possible to make some performance improvement by producing envelopes based on one main theme? (i.e. ratio based time lenght, so results of main code would be just scaled somehow?)

Hmmm. I'm not sure about this one. My first guess would be that maybe having the same module copied so many times might cause some issues with SM trying to accommodate the same variable names over and over. But this is just a guess. There really isn't anything out-of-the-ordinary going on in the code. It's pretty straightforward. I think that ultimately, the solution will involve incorporating all of the envelopes into one block of assembly. That way, we can take advantage of "interleaving" the hop routines and we can "share" values between them. When you figure out what configuration you ultimately would like, e-mail me a "wish-list" and I'll see what I can do. If you lost my e-mail address, just PM me.

-cyto