The CNFB Method

What's the ETA on seeing this in a public firmware?
well...applying some deductive reasoning: last year, in late January, a Fractalaudio thread appeared called something like "you guys are in for a big treat" in which a it was revealed that some secrets of chugging had been discovered - Cygnus beta was released in mid February, and first went to full production in April. So by this logic, I'd guess we have a CygnusX2 beta by some time in February, and if it's anything like CygnusX1, we are in for another treat indeed!
 
Last edited:
“Finally Perfected....”

....is a profound statement!! ...and a joyous achievement of a pursued goal!

The graph lines up perfectly!

It’s exciting to see just how this perfection will impact what we have now! ...which is already incredible now!
 
If I understand the purpose of CNFB correctly, there will be no need to re-measure amps, etc. as CNFB is mainly an optimized, new method of getting the same accuracy/results of the existing data/algorithms faster, which translates to much less CPU resources required, as well as making for easier/faster development of new modeling techniques/algorithms....it's a 'process' improvement.

That it'll free the CPU to 'do other new, cool stuff' is very exciting.

All of this makes for what is, assuredly, awesome things to come...
 
Last edited:
I just got the Turbo and is so powerful that I can’t even imagine how to reach CPU limits (with a realistic preset).

With such achievements the Turbo will probably get even more power to understand what my wife says while I play…😱
 
I just got the Turbo and is so powerful that I can’t even imagine how to reach CPU limits (with a realistic preset).

With such achievements the Turbo will probably get even more power to understand what my wife says while I play…😱
I got there pretty quick (with Full Res) on some of mine.
 
I just finished porting the push-pull power amp algorithm to the Axe-Fx amp block and (after some debugging) it works. It doesn't sound markedly different but it sounds slightly more open. Measures slightly different too. But we're talking tenths of a dB so...

Right now it's using more CPU than the previous version. I'll need to spend some time doing optimization.
 
I've finally perfected the "Chase Nonlinear Feedback" (CNFB) method for the modeling of nonlinear networks. And it works amazingly well. Has the accuracy of high-order integration methods with less computational burden.

Can simulate diodes, triodes, pentodes, etc. Far less error-prone than other methods (like K-method or DK-method, etc.) as you don't need to enter large matrices or tables.

It works on the principle that nonlinear devices can be thought of as linear devices with nonlinear feedback. You compute the states of a linear network and apply nonlinear feedback to get the output. It's also inherently stable. If the analog version of the network is stable, the CNFB implementation is stable.

The plot below is a simple example. This is a single-sided diode clipper with "memory" (the memory being a capacitor across the diode). The dotted line uses classic nonlinear ODE techniques solving the network using Trapezoidal Rule integration. The dashed line uses the CNFB method. The results are virtually identical but the CNFB method executes in about 60% the time (12 operations per loop vs. 20). As the number of nodes in a network increases the computational advantage increases proportionally.
View attachment 93791

Here's a more complex example. This is a plot of a 6L6GC push-pull power amp into a reactive load (blue) compared to the same power amp simulated in SPICE (red). Doing this with conventional methods (nodal K, DK, WDF, etc.) induces major thinky-pain. I did this with the CNFB method in a couple hours.

View attachment 93826

Could be a revolution in nonlinear network modeling.

60% the time? 😮😮
 
The FM3's really my first guitar processor & I've been playing for ~16 years now. Did my homework before I decided I was going to get a modeler & by that time Cygnus was brewing; I accidentally came across a FAS post on this forum while researching what the competition also had to offer. Then started reading some of Cliff's tech notes in the forum and it quickly became obvious that this man is a master of his craft - my search stopped there. Every time I plug into this unit, it brings a smile to my face. Thank you @FractalAudio to you and your team for having raised the bar this high.
 
Last edited:
Congratulations Cliff! Reading your post was like watching Paul McCartney write "GET BACK".... I could almost smell the ozone from the synapse's firing (your's, obviously not mine). I can't say I didn't understand ANYTHING you wrote, but I sure would hate to have to explain it to anyone.
 
I just finished porting the push-pull power amp algorithm to the Axe-Fx amp block and (after some debugging) it works. It doesn't sound markedly different but it sounds slightly more open. Measures slightly different too. But we're talking tenths of a dB so...

Right now it's using more CPU than the previous version. I'll need to spend some time doing optimization.
Cool stuff Mr Chase!

Not that I actually know anything, but for the folks thinking about how long and how much work, this post seems to point out that even if this approach is easier to code with, significant work is required to rewrite at least some pieces the new way. How hard, how long, how many pieces, don't think anyone knows, not even Cliff.
 
Potentially 40% more cpu for free!? I wonder if this will work for the effects at some level as well as the modeling? Seems it would be a major re-write of what we have, but Cliff has done this in the past, which blows my mind!
 
Potentially 40% more cpu for free!? I wonder if this will work for the effects at some level as well as the modeling? Seems it would be a major re-write of what we have, but Cliff has done this in the past, which blows my mind!
Potentially 40% of the CPU load of an amp block saved - not 40% of total capacity. Still, amp blocks use a fair bit of CPU, so savings may be enough to make a nice dent....
 
Potentially 40% of the CPU load of an amp block saved - not 40% of total capacity. Still, amp blocks use a fair bit of CPU, so savings may be enough to make a nice dent....
That also assumes the new method can be used for 100% of the tasks running in the amp CPU, and all of them have the same 40% saving.

Let's not be disappointed if it turns out to be 5% real would, which would still be much appreciated.
 
I just finished porting the push-pull power amp algorithm to the Axe-Fx amp block and (after some debugging) it works. It doesn't sound markedly different but it sounds slightly more open. Measures slightly different too. But we're talking tenths of a dB so...

Right now it's using more CPU than the previous version. I'll need to spend some time doing optimization.
I thought the new method was inherently more efficient, and by a decent amount. Just curious why you need to optimize just to get back to par.
 
Back
Top Bottom