RaazP

Ryzen 4xxx will be a big boost at the end of the year and Nvidia 3xxx will probably be released in August/September and also be a big boost in performance. 
 
So you might want to get a B550/x570 board with the ryzen 3600 to be able to easily swap it out for a ryzen 4600/4700 when they hit the market. 
 
And maybe hang in there with your current gpu and lowered settings. 
 
Apart from that: looks good! 

Im upgrading the cooler to the nzxt kraken x53 and reapplying the paste.In rust it gets about 75-79c which i know isn't good but again not terrible.Normally in games it gets 60-73c max but in games like rust and gta 5 and stress tests it gets about 75-80c and rendering in premiere pro 72c

Ryzen 4xxx will be a big boost at the end of the year and Nvidia 3xxx will probably be released in August/September and also be a big boost in performance. 
 
So you might want to get a B550/x570 board with the ryzen 3600 to be able to easily swap it out for a ryzen 4600/4700 when they hit the market. 
 
And maybe hang in there with your current gpu and lowered settings. 
 
Apart from that: looks good! 

Sorry, I mean the max temperature for Turing is 88C.
 
And yes, I also agree it's more of a "limit" than a target. I think we're on the same page.
I also agree with modern cooling. In a 20C ambient, and my 2080S pinned at 100% with an OC on, it never went over 50% fan speed, and never passed 65C. I think the heat wave OP is in is killing him. And while his temps are perfectly safe, I feel the lower he can get them the better (in general), and once the heat wave passes he'll have some great temps.

As Rem0o pointed out above, the behavior that RaazP described is not what FanControl does.  It's also not what I described in my example, where the fan speed gets stuck at an undesired speed and "slippery slope" behavior is needed.
 
So I trust Rem0o will not be sidetracked by RaazP's incorrect analysis of my example, and will continue to consider the need for slippery slope.  The pseudocode snippet below shows how easy I think it would be to include the slippery slope behavior.
[EDIT: Corrected a bug in my initial pseudocode: PrevStep must be set to ProposedStep at the end only if the step is actually made; else PrevStep must be set to 0.]
 
There are other names we could call it besides "slippery slope."  Perhaps "inertia" would be a better name, to suggest the fan speed% should keep stepping in the direction it has been stepping (assuming the next step will move it closer to the curve speed%) regardless of the hysteresis setting.  Another possible name is "zero sliding friction" to suggest hysteresis should not apply while the fan speed% is stepping toward the curve speed%.
 
As a coding technique, one could multiply the previous cycle's step (which may have been upward/positive or downward/negative or zero) by the proposed next step.  If the result is a positive number, this is the case when the proposed next step should be taken regardless of hysteresis, since in the previous cycle the fan speed% was stepped toward the curve speed%, which implies the fan speed% hasn't settled.  If the result is negative, the proposed step is in the opposite direction as the previous cycle's step, and nonzero hysteresis ought to prevent the step.  If the result is 0, then either the fan speed% had already settled somewhere (so hysteresis may prevent the proposed next step) or the fan speed% is already at the curve speed% and the proposed next step is 0.
 
Here's a snippet of pseudocode, in which the expressions highlighted in blue show a way to include the "inertia" behavior into FanControl:
 

Just to clarify, this scenario you mentioned is wrong. The fan curve will continue to go to the 71 degree point until there is a change from that 71 degree that is larger than the hysteresis. Even if it drops back to let's say 65, or go up to 75, it will still be at that 71 degree until the temp reaches 81 or drops back to 51 ( 20 deg hysteresis ). That creeping effect you are referring to doesn't exist.

Because I operate this as a donationware.

https://en.wikipedia.org/wiki/Donationware

Just to report back:
 
Thanks for telling me that my approach was "weird". I thought about it for a while..
 
Thought I'd try the different approach then and it runs nicely as far as I can tell from only 2 days.
One graph (gonna transfer this into just a linear one):
flat at 35% until 50°c, going up in a straight line to 100% at 83°c.
10°c Hysteresis, 10s response time
 
Second graph:
flat at 0% until 85°c, then 100% at 86°c.
4°c Hyst, 1s response time
 
Mixed into a Max mix.
 
I know, still pretty weird for you probably but I found out that my cooler is big enough to passively cool my CPU long enough to sub 90°c that the second graph is quick enough if I get 100% load on all cores from complete idle.
Which is more a fail safe.. Apart from doing a benchmark out of idle, there's no program I'm using that wouldn't cause some load before maxing out.
Once the slow curve responses, the temperature will always be okay.
 
Overall the fan speed history (openhardwaremonitor for 24h logging) looks very nice and I didn't get annoyed get by ramping up/down fans.

RaazP wrote: "I don't want burst cooling, quite the opposite. I want my fans to stick at a certain level, if an application will frequently heat up the CPU above a certain temperature."
 
Perhaps RaazP could achieve his goal if FanControl were enhanced to provide a second {hysteresis,responsetime} pair in each curve: one pair for rising and the other for falling. (Similar to the request by several users who have asked for two stepsizes in each fan control: one stepsize for rising steps and the other for falling steps.)  RaazP could then set a large hysteresis and a large response time in the pair that applies to falling cpu temperatures, to prevent the fan speed from decreasing until the cpu temperature has a large decrease.
 
FanControl might need to provide "slippery slope" (a.k.a. "low sliding friction") too, to prevent a combination of large hysteresis and small stepsize from causing the fan speed to get stuck partway along the curve before getting close to the target speed.  In other words, hysteresis would prevent the fan speed from taking a step when temperature has changed only a small amount, but once the fan speed takes a step, the slippery slope would cause fan speed to continue to take steps regardless of the hysteresis setting until the fan speed target is reached. (I'm assuming FanControl doesn't already implement slippery slope.  I haven't experimented to see whether it already does.)
 
I expect the code to implement the second {hysteresis,responsetime} pair would be simple, and there's plenty of display room available in the user interface for the second pair since it would be displayed only in the popup that appears when the user clicks the curve's Edit button.