incorrect export labels - bug report
In the future, should I report bugs here or via email to sigmadsp@analog.com? I get warm a fuzzies posting here rather than email because Jerad and Brett are so awesome!
I found a bug in SigmaStudio 3.3r613 using an ADAU144x
The "First Order w var Param/Lookup/Slew" module found in Filters->FirstOrder->Lookup->Double exports duplicate labels for unique ADDR, FIXPT and VALUE fields which causes compiling problems. Naturally, the problem gets worse when Adding or Growing the module. The TYPE field also has the same problem but since the data field is the same the precompiler is happy.
These values are incorrectly redefined
#define <NAME>_ALG0_FIRST_ORDER_COEFF0_ADDR
#define <NAME>_ALG0_FIRST_ORDER_COEFF0_FIXPT
#define <NAME>_ALG0_FIRST_ORDER_COEFF0_VALUE
#define <NAME>_ALG0_FIRST_ORDER_COEFF1_ADDR
#define <NAME>_ALG0_FIRST_ORDER_COEFF1_FIXPT
#define <NAME>_ALG0_FIRST_ORDER_COEFF1_VALUE
#define <NAME>_ALG0_FIRST_ORDER_COEFF2_ADDR
#define <NAME>_ALG0_FIRST_ORDER_COEFF2_FIXPT
#define <NAME>_ALG0_FIRST_ORDER_COEFF2_VALUE
bug
export
sigmastudio
SigmaDSP
MagicRub,
I answer the sigmadsp@analog.com address, so your question is getting delivered to me either way. I would prefer that you post anything that isn't confidential or too application-specific to the forums. The great thing about posting in the forums is that the answers are immediately available to the entire community.
By the way, Jerad recently transferred to our MEMS Microphone division, so for now I'll be holding down the fort here in SigmaDSP territory. I think the MEMS group will be getting their own forum section soon, so Jerad will probably still be active on EngineerZone answering MEMS microphone questions.
Thanks for posting this bug. We've seen a few issues with duplicate defines in the past. I will post this issue on our internal bug-tracker and hopefully it will be addressed by the software team soon.
The compressor delay problem you mentioned is a known issue and it was fixed on February 8th. Expect it to be in working order in the next SigmaStudio release.
From the developers:
The order of restoring values to the control after saving was wrong. This led to the decay value being set to the default RMS_TC value. This is now fixed.
Thanks for your bug-hunting! We definitely try to find all of the bugs we can before releasing a new version, but sometimes some bugs slip through and it's very helpful to us when you report them.
We are currently running on a target schedule of one beta release every two weeks. I expect we should stay pretty close to that target, so I think a new beta might be available by the end of this week or next.
Bummer to hear about Jared, hope he's happy over in MEMs!
While we're on the topic, I have another bug for you. I've noticed some of the compression modules don't rememeber their values correctly when you close and reopen the project. If I remember correctly, they do save sometimes but only when below a certain threshold but otherwise revert to 120dB decay. Off hand, the DynProc->RMS->Std->Low->NoGain->N-chanel comes to mind.
"..the next SigmaStudio release"
Any eta on that?
Please log in to reply.