How to eliminate 'click' problem?

[tester]

Two problems.

1) You removed midpoint (envelope) control, which I use (the thing set temporairly to -12dB).

2) This solution eats a lot of CPU (multiply by 16+ mono4) - few percent more. Can this be rearranged to be added somehow to a whole signal, with separate control of fadein/fadeout time? I don't know, maybe only sample accurate fadeout would be enough, fade in can sta where it is right now.

[schematic(s) posted here are simplified, but many other parameters and variations (and experimentation routines) are in the game].

[KG_is_back]

Oh... like this?

[tester]

Theoretically, but... Attached picture shows 3ms span with click if fade out is set to 10ms. So it's similar to what I did or the same.

I see following sources of that out-of-sync problem.

1) Either this has to do with some inaccuracies due hop within the source timer (made by fellow friend on SM long time ago).

2) Or it has to do with roundings in float domain (envelope clock performs some different calculations than anticlick, so maybe issue relies here?)

3) Or the phase shift applied to ine input - is delayed within the primitive

4) Or "changed" should be delayed between some of the routines.

So or else, you can hear it, and you can see it. What appears to be fade out - is about 40ms prior to the phase change if I see it correct (I can be wrong).

[tester]

Possible theoretical solution. An idea.

"Changed1" is sent to that "fade out" timer. After output reaches zero - "changed2" impulse is sent from that timer module - to individual envelopes (and phase offsets and all other kind of stuff). Thus - there should be no rounding problems. Or? (...should be something else delayed by 1 sample?)

[KG_is_back]

I think I have it worked out. I've recreated the envelope maker and the clock. Function-wise it should be the same but save a little CPU (there's still room for optimizations though).
The envelope and the click remover have separate clocks. The clock of the click remover has initial delay smaller by the length of the fade-out. This way the phase change happens exactly in the moment when the amplitude is zero. Only problem is, you can't change the fade length while the thing is running, because they get out of sync (clicking resync button fixes that immediately, so it's not such a big problem).

Fade in and fade out can be set separately. Envelope is exponential decay and is set by two parameters - TIME (in seconds) to reach certain RATIO (in dB).

[tester]

Okay, it seems to work. Thanks for great work and time spent on it!
(now a heck of work on instrumental coeffs and other switches)

[KG_is_back]

Okay, it seems to work. Thanks for great work and time spent on it!
(now a heck of work on instrumental coeffs and other switches)

The "beating" of the frequencies is present, because sound travels at different speed in two directions in the sining bowl. This can be simulated by having two oscillators that are slightly out of tune. The detuning can be measured- the oscillators must be detuned by the frequency of beating.

f_osc1=frequency
f_osc2=frequency + beating frequency

When you mix osc1 and 2 they will produce the beating - the depth of the beating depends on the mixing factor.

You might also consider using very narrow bandpass filters (Q close to infinity) and excitation pulses to model the bowl, instead of "simulating" it with oscillators.

[tester]

Something is wrong with the decay (fade out) curve? It isn't reaching zero at specified time. I know it's a simplification, but right now the control of the fadeout+midpoint sounds unnatural.

Ah, I see, you changed the nature of that curve. Well - not without a reason I had the midpoint (to control the slope) and end time (=floor).

[KG_is_back]

Something is wrong with the decay (fade out) curve? It isn't reaching zero at specified time. I know it's a simplification, but right now the control of the fadeout+midpoint sounds unnatural.

Ah, I see, you changed the nature of that curve. Well - not without a reason I had the midpoint (to control the slope) and end time (=floor).

It works fine here. It may fail to reach zero perfectly in case the fade-out is not sample accurate (is not integer samples long). However, either case it should get so close to zero it's basically ducking.

[tester]

Something is wrong with the decay (fade out) curve? It isn't reaching zero at specified time. I know it's a simplification, but right now the control of the fadeout+midpoint sounds unnatural.

Ah, I see, you changed the nature of that curve. Well - not without a reason I had the midpoint (to control the slope) and end time (=floor).

It works fine here. It may fail to reach zero perfectly in case the fade-out is not sample accurate (is not integer samples long). However, either case it should get so close to zero it's basically ducking.

I'm using your schematic right now, nothing else. Fadeout is set to 3sec (via "fin" node, reused for different purpose as I can see). I changed the interval to 10 seconds, and restarted audio, and I can hear the thing all the time, pretty loud. Should be zero at 3 seconds after hit.

After 3 seconds it is -12dB, so the 12dB is no longer the midpoint.