DSP-Quantizer class in C++
I see a number of things that may help you improve your program.

Omit empty destructor

The compiler will automatically generate a destructor that would, in this case be identical to the empty one your wrote.  It's better to simply omit it and let the compiler do its thing.

Cleanly separate interface and implementation

In all, the files are fairly neatly divided, but I'd make a couple of changes.  First, I'd move the #include &lt;cmath&gt; to the .cpp file because it's an implementation detail (and as you'll see a bit later, might not be necessary).  Second, I'd remove the processOneSampleLinMidtread() and processOneSampleLinMidrise() from the .h file and make them static free-standing functions in the .cpp file.  More on that in a moment, too.

Avoid comparing floating point numbers for equality

It's generally a good idea to avoid comparing floating point numbers for equality, even if it's only comparing with zero.  See the oft-cited and still excellent What Every Computer Scientist Should Know About Floating-Point Arithmetic, by David Goldberg for a readable technical discussion for why this is so.

Reconsider the interface

At the moment, there's no way to read back out how many bits are in effect and no way to find out what the digital encoding would have been for a particular input float.  I'd suggest a couple of changes to address that.  First, it is probably useful to provide functions for reading back the publically settable parameters.  Second, I'd suggest splitting the current processOneSample into two pieces: int encode(float n) which would return the binary encoding of the input n and float decode(int x) which would return the corresponding floating point value for the encoding x.

Reduce repeated calculations where practical

The expression powf(2.f, m_nBits - 1.f) is used very many times within the class, but it only depends on m_nBits and not on any other value.  For that reason, it would make more sense to calculate it once and store the result.

Avoid floating point where practical

It's often faster to do integer mathematics rather than floating point.  For that reason, and because we know that the result of powf(2.f, m_nBits - 1.f) is always going to be an integer, I'd suggest instead to calculate using the expression 1 &lt;&lt; (bits - 1).

Use standard library features

Instead of the current code checking for upper and lower boundaries, it's much more succinctly expressed using std::clamp if you are using a C++17 compiler.  If not, it's not hard to write your own version.

Use const where practical

The processOneSample() routine does not (and should not!) alter the underlying object, so it should be declared const.

float processOneSample(float in) const;


Think about future uses

Many people agree that the YAGNI principle is a sound one, and I agree with that.  But there is a balance between only coding what's needed right now and anticipating at least the possibility that there may be future uses.  An example in this case is using other kinds of digitizing algorithms such as A-law or \$\mu\$-law for audio digitizing.  An alternative approach might be to have a base class (possibly virtual) and then derived classes that implement each kind of alternative encoding.

Think about whether you need a class at all

This may seem heretical for C++, but not everything needs to be an object.  Really what this code is about is turning one floating point value into another.  It may be that freestanding functions (with the appropriate parameters) might work as well.  It depends on how often you anticipate changing the parameters of the base object vs. how many times processOneSample is used.

Consider using a modern constructor style

An alternative to this constructor:

CQuantizer::CQuantizer(CQuantizer::qType type, int nBits, float amplitude)
{
    setType(type);
    setNBits(nBits);
    setAmplitude(amplitude);
}


might be this:

CQuantizer::CQuantizer(CQuantizer::qType type, int nBits, float amplitude) :
    m_nBits{nBits},
    m_amplitude{amplitude},
    m_type{type}
{}