Stereo Tool

Exception Handling would tell you.

#include <exception>
int main() {
try {
// do something (might throw an exception)
}
catch (const std::exception& e) {
// handle exception e
}
catch (...) {
// unknown exception, should not happen
}
}

The debugger told me. I was doing a memory write at address 0xffffffff according to the debugger - but that actually means that there was an unaligned SSE2 write using an aligned instruction (_mm_store_si128 or MOVDQA vs. _mm_storeu_si128 or MOVDQU) - the real cause of this was that I forgot to allocate a variable with __declspec(__align(64)). (I probably lost almost everyone now)

I'm don't see how an exception handler would have helped here - it could have prevented the software from crashing but the audio would still be completely unusable. And in order to find where the error came from I couldn't use the normal release build because it's so far optimized that the debugger - even with .pdb file present - is unable to determine even from which file it comes.

Where can I find Jeroen's (aka phantomfm) preset for download ?

Where is the updated version of your drz fat bass preset ?

viewtopic.php?p=19136#p19136

You have a fundamental misunderstanding of exception handling. You are confusing it with error reporting and/or the "on error goto" technique that would keep the application running. My guess is that you came from a Pascal / C background. C doesn't technically support exception handling. C++ does.

Exception Handling does not mean that the application remains running!

Sure, you can choose to let things keep running, but you don't have to. The handling routines are written by you, so you can have the application do whatever you want it to do.

If you want it to hard lock, then you can make it hard lock. If you want it to shut down gracefully, you can have it shut down gracefully. If you want to have it shut down gracefully *AND* produce relevant call stack information, you can have it do that.

Most importantly: If you want to include an opt-in "submit crash reports" for users, you can get alerts to exceptions that were missed due to not testing that specific scenario.

You need to read up on exception handling.

What I'm trying to say is: Even if I attach the debugger to it AND have the .pdb file present it's still impossible to find out where an error occurred. That stack information? Not there due to all the optimizations that occurred. The debugger can - even if the source code is present - only display assembly code because it cannot find where the crash occurred due to - among others - VERY aggressive inlining between object files.

It would be there if I would turn a lot of compiler optimizations off (including some related to exception handling, usage of registers intended for debugging etc. for normal usage etc) - I could, but it would make the whole code a lot slower.

To be able to find and useful debugging info, and stack info, the only option I have is to turn all these compiler options OFF. And then there's suddenly a lot of useful info available. That's how I managed to find the cause in 1 minute - but only after waiting for 15 minutes for the less optimized build to finish.

New attempt: BETA037:
- New MB displayed in bottom section (not yet in smaller view)
- MB steepness configurable PER BAND and even PER SIDE, and visible
- AGC Compressor added
- New Big O V2 preset added Equalizer settings are lost! Will fix that tomorrow... Sorry Also the steepness values should have all been at 49 instead of 32!

Stand alone: http://www.stereotool.com/download/ster ... 04-037.exe
Winamp DSP: http://www.stereotool.com/download/dsp_ ... 04-037.exe
VST: http://www.stereotool.com/download/vst_ ... 04-037.dll

Poking around on Google suggested a performance penalty can happen by not properly declaring static functions, where that penalty includes an inability to as aggressively inline.
I have thus far completely been unable to find a reference to what you're talking about.

What I will tell you is that Intel's own sample files for Intel Integrated Performance Primitives use exception handling. Intel Threading Building Blocks also use exception handling.

If Intel is using it, specifically in a product with the word performance in its' name......................... maybe it has some merit?

Not long ago, it was thought that Pow() and Log was "as good as it gets", at least until the idea of a lookup table was introduced. Perhaps this is similar?

Hans,

Thanks for 037 Beta, will be tweaking my preset tonight with the steepness parameters.
Will share the optimalisation.

In my oppinion the new multiband has great potential and yes my preset still needs some tweaking but it's a good starting point for all you freaks out here !

If you have comments on the preset please let me know, it was developed onair in a standalone setup so it possably needs some tweaking on each transmitter.

_________________
----------------------------------------------------------------------------
AIRCHAIN-GURU professional independant airchain consultancy.
Orban/Omnia/Vorsis/DSPX/Aphex/Inovonics
----------------------------------------------------------------------------

Been up late, so I looked around...

I think what may be confusing is my referencing just exception handling. In my mind, I bundle crash reporting with exception handling. I don't independently list each one. The reason I don't is because it just makes sense that you'd do a crash report when you attempt to handle exceptions.

Exceptions, by definition, should be "exceptional", meaning that they are rare events.

Error conditions / status codes / return codes are NOT what I'm talking about when I talk about exception handling.

Your unaligned memory access is an exception. It is an error condition, but notably it is an exception. More specifically, it is an unhandled exception, which means that it leads to a crash.

Handling exceptions does not necessarily mean allowing the application to continue. Yes, you can write code to swallow the exceptions, but that's not good practice. Other issues may come up later due to not properly cleaning up after the exception.

Contrary to what seems to be believed, you can get valuable information by handling an exception and generating a crash report. If there was no use for this, I don't think there'd be as many books on the subject....

Lastly, I ran across a comment about how no matter how "clean" of an exit a hard application crash is, it is highly user unfriendly and generally should not be done. It leaves the user scratching their head. They will typically try over and over, and then get frustrated with you and your software.

I know this goes against your previous experience, but maybe you might take a look into doing things differently. As you are obviously trying to add a lot of commercial features, hard crashing the app and leaving users frustrated is probably not the most strategic approach to long-term economic viability and success.

The Intel AppUp SDK seems to have a very nice crash reporting mechanism. The only gotcha is that it requires usage of either Visual Studio or Eclipse.

respect to the GRaph.!!!!! rules.!
Testing..!!!

_________________
Sexy Girls in your city