There are many C++ errors in this code. I believe it is this one that causes the issue…
You are casting an uint16_t to a bool implicitly, what do you want that to do? In c++ you should follow the type system and avoid the implicit casts c has.
Further, you are taking the bitwise ‘and’ of some number and 1, this is the equivalent to asking if the number is odd - you should just do this the normal way with mod, the compiler knows what it’s doing.
So I believe your code will produce the value 1 when mVal is odd.
Have you checked your bit-shifting can produce even values given all states and given the initial state?
I wasn’t thinking about mod, I was just thinking of the LSB, but you’re right. I caught a few of the issues, like a weird static cast to the wrong type. I’m pretty new to C++ as I’m sure you can tell, so I’m trying to get some practice in by making plugins for SC and VCV.
What I thought would happen is it would give -1 while mVal’s LSB is 0 or 1 if it’s 1.
I added a conditional statement to reset mVal to -1 if it gets to 0, but I don’t think it will. I could be wrong. I don’t know how to do the math to figure it out. I have a separate code to just print LFSR states and it gives this as a small sample given a feedback position of bit 15.
I think the problem might be I’m not really sure how the frequency argument should work. MySaw2 and Mads’s RampUpGen approached frequency in two different ways that I wasn’t totally sure how to implement. Again, not great with math.
Is that large code snippet the values of mVal? If so, it looks like it should work now? Perhaps replace add the logic to switch on odd and check that works to?
That’s 2^16 - 1. You can use the numerical limits in c++ to write this much nicer.
Unless frequency is larger than the sample rate, it will always be 0 … Or perhaps it will be 1 if it’s greater than fs/2… I can’t remember, point being, don’t use a cast to change a value, instead use round, floor or ceil.
This isn’t necessary…
uint16_t val = this->mVal
I get what your thinking, let’s not do the pointer deference everytime we look at mVal … but the compiler knows this and will fix it for you given that ints fit in the register, you can just write mVal directly everywhere. You don’t need the ‘this->’ either.
This branch is currently impossible as min pos is 0 and ‘pos’ is a uint.
Ok I’m starting to see where some of the issues are, thanks for your help! I think I’m going to have to step back through this a little more carefully and try some other less flexible designs first to build out from there
Here it is not necessary because the variable is an integer. However, if it were a float you would indeed need to copy it to the stack, otherwise the compiler must assume that it may alias one of the output samples and reload it from memory on every iteration!
Usually, you can rely on optimizing compilers to do the right thing, but there are still cases where they lack information and need some hand holding.