Hi. I've played with this method before a bit. A real 1-pole lowpass filter with an impulse passed in is equivalent to multiplying every previous sample by a constant factor to get the next sample, which is also equivalent to an exponential envelope. But you can also add a constant factor for every sample in order to make a linear envelope. So it turns out you can make a variable-slope filter by combining: multiply and add on the previous sample by 2 different factors. If you are interested I have further details in this blog post:
https://sshader.wordpress.com/2014/09/05/programming-an-adsr-envelope/?iframe=true&theme_preview=true

It's not that cpu friendly when you change the settings because you have to take the sample-length-of-the-stageth root or something like that, I haven't looked into it in a while though. However, afterward it simplifies to an add and multiply at every sample

here are the codes: http://forum.pdpatchrepo.info/topic/8490/examp-exponential-envelopes-with-exponential-linear-curve-control

A few pointers, if you might allow me to expound:

The equation describes only equal temperament, and the 69 MIDI value is to correct for the value of the reference key of A4, above middle C.

The assumption of equal temperament proves a repetitious vexation, denotes ignorance, apathy, laziness, and/or unfamiliarity with the math of music. Worse, this assumption proves far too common among engineers / mathematicians / scientists / software programmers. Which then deprives us musicians of useable tools, and the stupidity of the need for MIDI tuning standard / scala / etc, is the vacuum such engenders.

Troubling how in this modern age, they teach his geometric theorem, yet not his music, nor his math relevant to music. Yet we laud him as the grandfather of the Western tradition of music, owing to his discovery and delineation of the mathematic definitions in ratios of the twelve notes of all of Western music. Pythagoras of Samos might well concur: the math we teach is a decrepit wretch of an invalid -- incomplete, fragmented, not useful, and regarding certain fundamentals, dead wrong.

How few know how, when, and why the value of the third decimal onward ad infinitum of Pi needed to be re-evaluated, recalculated for better precision in the latter part of the 20th century, for instance. Yet how few are taught the corrected, more precise value of Pi -- in any school or university in the land? Pi had to be re-evaluated in the 1960s given the orbits of our species' earliest satellites resulted in the falling-back to earth of each one of them due to the value of Pi we were and still are taught in school is not precise after the second digit. The circles we calculated the orbits to be proved each to be slightly short of a true, pure circle, thus returning the satellites to the ground. Pi more precisely can be evaluated to 3.1446055, and not the perpetuation of imperfection, and the maintenance of ignorance still taught today.

Hope this helps,

F.

Exponential fades are not circles, but they do look a bit like ellipse quadrants. If that's not what you mean, you'll have to find a picture (or look here). If it is, here you go: Exponential curves on linear impulses (not dB) sound smooth and straight, because the ear translates takes a logarithm of them (as it does with frequencies) to become linear. This is called an exponential fade. By changing the base you can affect the sharpness of the fade.

Generally you want to avoid finding matches on a curve for your time & amplitude, so you'll stretch the exponential's known points to your start and end points and amplitude. Exponentials of all bases b go through the points (0,1) and (1,b), and we want them to go through (start, volstart) and (end, volend).

Crop the output by subtracting 1 from the whole function, so that b^time becomes b^time-1 (not b^(time-1) ), and those points become (0,0) and (1,b-1). Stretch the amplitude by dividing by b-1 and multiplying by volend-volstart, sending (1,b-1) to (1,1) then (1,volend-volstart). The function is now: (b^time-1)*(volend-volstart)/(b-1). Raise this clip to meet your desired amplitudes by adding volstart, so that the points are now (0,volend), (1,volend), and the function is (b^time-1)*(volend-volstart)/(b-1)+volstart.

All that's left now is stretching and clipping the input, which can be done a number of ways, but all entail turning start-end into 0-1. You can give this expression a time input from a [line] that ramps from 0 to 1, from start until end in ms. You could, of course, run that line through another function first, which still outputs from 0 to 1, and make a more complex envelope. You can bake the stretching and clipping into the expression by turning time into (time-start)/(end-start), so that as time runs from start to end, the function outputs as if running from 0 to 1.

@Maelstorm said:

I fairly recently was trying to make one of those smoothed-out sample-and-hold LFOs and discovered that [lop~] generates asymmetric curves: logarithmic going up and exponential going down.

Well, it's actually exponential both ways, but it's always exponentially decaying toward the destination value. So going up it's an inverted exponential decay.

But if you're considering something like an amplitude envelope, you may want the rising portions to be an exponential decay (most analog envelope generators work this way, moving to the next stage at a preset threshold). A DX7 has a true exponentially increasing attack (since it's a linear function passed through an exponential lookup table), but it sounds strange and sort of unmusical, like a sound played in reverse.

As suggested in the tutorials, quartic envelopes are a nice compromise. The curves are exponential-like, but they reach the destination values in a finite amount of time.

Just ask God that works for me and don't stop using of pd and know I know how to use synth edit and other things like that and keep up with math and find a dps class if you can. It's sad to say this but I really whont to move to c sound because its more complex and I am tying to find classes for Dps my self and I missed out while I was in high school how important math was I wish I would have just learned more math. And also think out side of the box will help you to make things that will blow people away.

I don't understand the most boxes... but it works! THANKS, MAELSTORM! I gave a threshold of 70 and decay, for the moment, it's ok on 250. When I test working together with Blender, maybe I'll change those numbers.

Now... I have to bang the OSC messages. I need something like this... but in PD:

Min = minimum #when I am speaking
NTP = numbers.to.process #gotten from...? snapshot~?
mouth_open = False

if not mouth_open and NTP > Min:
mouth_open = True
bang(open_it)
elif mouth_open and NTP < Min:
mouth_open = False
bang(close_it)

How...?

Thanks Katjav, but these patch only detects peaks... Let me explain with the PNG I've attached.

When I'm not speaking, my puppet doesn't move the mouth. The "voice detect number" (VDN), would be at 0 (zero). When I start speaking, a peak detect would lift the VDN to 100, for example. There would be a minimun limit to know when I am speaking. Then, a smoother would smooth the VDN to avoid go down below the minimum. But if I stop speaking, the VDN go to zero.

When VDN is more than 50, I am speaking. A bang is shooted to a "start moving the mouth" command sent by OSC. Below that, I'm not speaking... another bang is shooted to a "stop moving the mouth" command.

I think this patch would have the fiddle~ object.

http://www.pdpatchrepo.info/hurleur/voice_detect.png

I'm having some problems, each time i do the maths for each pixel (500x500) the cpu gonna very loaded doing the maths slowing the music...
then i tryied to use gl shader language, but i'm with some dificults because i'm new in shader and pd and GEM.... so i dont know where i can write the codes before render (init() codes)...

i tried write:
shader1 = new Glsl("hello.vert", "hello.frag");
at the construction method, because normaly is writen at main, but then the object in pd is cannot be created...

well maybe is a very confused post but if you can help me to do these render's maths in shader at this external it will be great...

these are the commands i use to compile the project:

gcc -c fractal.cpp -o fractal.o
ld -export-dynamic -shared -o teste.pd_linux fractal.o -lc -lm
and
sudo mv teste.pd_linux /usr/lib/pd-extended/extra/

thx if anyone can help...

Here is my new formula / method for an exponential test chirp.

sin((((pi/2^p)*L)/ln(2^p)) * e^((n/N)*ln(2^p)))

condition: ((pi/2^p)*L/ln(2^p)) = M*2*pi

M = a positive integer
L = a decimal number (floating point number) expressing chirpsize in unity samples
N = ceil(L), that is L rounded up to an integer, the real arraysize
p = the integer number of octaves in the chirp (user argument)

With this method, you get a chirp with evenly-spaced octaves. The chirp starts in sine-phase and also ends in (approximate) sine-phase, thus minimizing the ripple height. It is even the case that each octave starts and ends in approximate sine-phase, whatever use that may have.

The crucial element in the method is the exponential curve at index 0 and N.

e^((0/N)*ln(2^p)) = e^0 = 1
e^((N/N)*ln(2^p)) = e^ln(2^p) = 2^p

Notice that ((pi/2^p)*L/ln(2^p)) is a constant. If this constant is an integer multiple of 2*pi, the exponential curve will start with 2*pi and end with an integer multiple of 2*pi, since 2^p is also an integer.

Using this method, the start frequency depends on the sampling rate and number of octaves. The start frequency is (sr/2)/2^p. For example: (44100/2)/(2^10) = 21.53 Hz. The stop frequency is always near Nyquist, with a small deviance resulting from the rounding of L to N. For large N, the deviance is negligible for all practical purposes.

If y[n] is the chirp, the inverse chirp is formulated:

y[N-n] * -ln(1/2^p) * (2^(p/N))^-n

This calculates an inverse chirp with average power equal to the forward chirp. That means, more than unity peak level in the high frequencies, and less than unity in the low frequencies.

The user supplies a maximum length argument in nr of samples, and the required number of octaves. From this, a new object [expochirp~] calculates the first ideal length L below the maximum length. It returns the integer chirp size N as a message (so you can resize arrays), and starts feeding chirp and inverse chirp to the signal outputs.

Chirp and inverse chirp can be stored in a 32 bit float stereo .wav file, but the risk is that someone will play the stereo file in a regular soundfile player, which for the inverse chirp could lead to severe clipping. The reason for normalising to amplitude instead of unity peak level is that no further information is now needed about the chirp for normalisation after deconvolution. That normalisation will be simply N/2, like it would be the case for a linear chirp. For safety, chirp&inverse could be stored as .txt files instead of .wav. I don't know yet what is wise.

Although my expochirp method so far guarantuees a straightforward chirp with minimized ripple, the ripple is still considerable, and at the low frequency side quite problematic in my view. Some speaker systems may already have their own resonance frequencies in the region of the start frequency. Therefore this is exactly the region where a flat chirp spectrum is most important, to not push eventual resonances to further height. I have experimented with correction filters on the IR, but it would be better to relieve the problem at it's origin again, the shape of the chirp itself. I am now trying to find a fade-in window for that purpose. Windowing means amplitude modulation, causing sum- and difference frequencies. A proper window may cancel ripples, but a bad window could easily amplify them, or not? For me this is a new research topic. Only when results are acceptable I will finish [expochirp~] and share it.

Katja

Bassik, there may be some confusion. This last patch chirp~test.pd is only a patch to test the qualities of the generated chirp itself.

I am kind of swallowed by details of the method. Instead of quickly producing a working IR measurement tool, I am now trying to refine the method, starting with refining the chirp itself. Last time I mentioned the sensitivity for parameter settings. Now I have found a systematic method to optimize a chirp. The formula is different from the regular ones as found in texts. This has lead to yet another chirp object [expochirp~] (yes it's exponential, not logarithmic, also see Farina's 2007 article).

The regular exponential chirp formula's make a chirp start at sine phase to avoid a step, but they do not care about the phase at the end of the function, therefore it may well end with a step and produce excessive ripple at the high spectrum end. This is traditionally relieved by windowing, or by manually cutting the chirp at the last zero-crossing as Farina suggests. My new formula computes the chirp in such a way that it will start and stop in sine phase. No need for windowing or cutting, and the ripples are minimized.

Still there will always remain ripples in a chirp's spectrum, and I am now trying to produce inversion-filters to clean up a system's measured IR. For the high spectrum end, this is fairly well possible. But in the low spectrum end, where it is more important, the ripple character of exponential chirps is such that conventional methods fail. I did find some solution but it's not without compromise. Therefore I am investigating alternative methods.

I am sorry that proceedings are slow now. But my hope is to contribute to a good quality tool in the end. I'll post details on the new chirp formula soon.

Katja