May 26, 2016
Hey Will/other readers
Is there any plan for exception handling built into RackAFX? Or the application reporting a plugin crash instead of crashing itself?
I'm currently having lots of issues tracing back problems when I'm debugging that I've verified are bugs in my code, but the errors/crashes don't happen until an unhandled exception gets thrown after a kernel level call. For example, my plugin is crashing when audio playback in RAFX stops. I can only look to the callstack as far back as calls from portaudio_x86.dll to KernelBase.dll, and some obfuscated code from RackAFX.exe (the last call is RackAFX.exe!00553249(), if that helps).
My issue is that because I don't have access to the code being called there, I don't have any way of tracing back to my plugin exactly what I'm doing wrong. It would be really helpful if RackAFX handled exceptions like this and printed them to the status window instead of crashing, with some information about what code being called from the plugin is leading to the potential crash. As it stands now, I just get these unhandled exceptions causing a total application crash.
It would be awesome if RackAFX implemented something similar to Bitwig, where plugin crashes don't cause application crashes. Just having a crash reported with some information about what happened or what to do (a FAQ link maybe?) would be fantastic.
Or if there's a total workaround I'm missing, that would be awesome too.
January 29, 2017
There are no plans to include any more exception handling in the near future (there already is some for low level RAFX internal stuff) however I may add some exception handling to later versions, especially with regards to loading the DLL itself. The "toxic constructor" issue is the most common.
Have you ever tried debugging a VST/AU/AAX plugin with Reaper, Cubase, ProTools, Logic or Ableton? I experience the same issues when debugging plugins in those clients - there is no internal code to look at and it can certainly be frustrating, because you wind up having to make educated guesses. And, they rarely handle exceptions well - just crash and burn midair - I have not used BitWig, for the record. I spent a good chunk of my free time last week trying to debug a VST2 plugin in Ableton, which has no exception handling for plugins either.
My grad students have been doing debug logging to a text file for finding the solution to crashes in addition to placing breakpoints all over their code.
Regarding your problem with a crash after audio is halted: check your Edit Project settings and see if there is a "tail time' setting (this depends on your version of RackAFX). When audio stops in older versions of RackAFX that do NOT have the Tail Time setting, buffers simply stop flowing into processAudioFrame(), which will not be called again once the last buffer has been processed which was ongoing when the user stopped the audio. If you do have a Tail Time setting that is non-zero, RackAFX will pipe buffers of 0's into your processAudioFrame() for the time you supply in that setting. After processAudioFrame() stops being called, RackAFX does nothing. It does not call prepareForPlay() again or any other function on your plugin until the user either moves a control (userInterfaceChange()) or restarts audio (prepareForPlay() followed by processAudioFrame() in the loop).
If you have a tail time setting that is nonzero, then a crash after play has stopped can be a result of underflow in IIR filters. If you are using the built in CBiQuad object then it has underflow checks built in (see the doBiQuad() function).
Another option you have is to use the Make VST operation and create a VST3 project with your RackAFX plugin as the core. Then you can debug your code in BitWig or any other DAW that you feel may have better exception handling or error reporting. It is easy to place breakpoints in your RAFX core code the same way as you do when debugging in RAFX.
January 29, 2017
Oh, you can also debug your RAFX DLL directly in any VST2 or VST3 client since it can be loaded in these clients.
Just right-click on the Solution in the Solution Explorer and choose the Debugging part; note that the executable is set to RackAFX.exe -- you need to change that by browsing to your client's executable (e.g. ProgramFiles (x86)/REAPER/reaper.exe). Also make sure that Attach is set to YES.
Then, copy your DLL from the Plugins folder (in RAFX choose PlugIns -> Open Plugins Folder) to your VST2 or VST3 plugin folder; if using VST3, rename the extension from .DLL to .VST3. Next, launch your VST client. Then, start the debugger in Visual Studio and place a breakpoint in the plugin's constructor. Load your VST plugin and the constructor breakpoint will be hit - at that point, you can populate your plugin's functions with breakpoints and begin the debug process.
So you can fairly easily debug your plugin in a non-RackAFX client.
January 29, 2017
I have uncovered an issue with the WDM Drivers and the PortAudio library. It is only an issue in the Beta version, not 184.108.40.206.
If your driver type is WDM, you can't run RAFX in full-duplex mode (which is only needed if you want to have a side-chain from Line In).
In View->Preferences, check the box at the bottom that says "Disable Full Duplex operation" and see if that fixes your crash-on-stop.
Most Users Ever Online: 36
Currently Browsing this Page:
Guest Posters: 1
Newest Members:strings4v, TheSmile, semihyavuzz, alfredLue, danioc, midnightskate3, Alia5, Shamal Sundar, Walker, Brad
Moderators: W Pirkle: 208
Administrators: Tom: 67, JD Young: 80, Will Pirkle: 0, W Pirkle: 208