I’ve benefitted from much of the AAX work that’s come from other members of the forum. I can’t say much here because of my NDA with Avid, but there are issues that have recently come up on the 64-bit side of the world. If you’ve been working on the AAX part of juce, perhaps we could get in contact. I don’t know the insides of the format as well as some of you do, but I stand ready to help. Please PM me if you’ve been working on this.
Running 64-bit AAX, I’ve been getting a lot of crashes in the AAX wrapper in the algorithmProcessCallback call (line 715 in the AAX wrapper). The crashes are access errors. Control doesn’t get down in the parameters.process routine–the crash is right there in the callback itself. Looking at the callback function, there really aren’t than many accesses. There’s a read of the iterator and a couple of indirections. That’s enough to cause the crash.
I’ve been able to get this crash simply by instantiating and deleting a plugin–without even rolling. A half-dozen times or so will do it. It seems to me that either of two things is possible.
[list]The DAW is calling this routine when it shouldn’t (it is a beta version of the DAW)
The JUCEAlgorithmContext structure isn’t set up quite right.[/list]
I’m afraid I’m having a hard time figuring out how the context is set up, so I’m throwing this out in case someone else has a better handle on it. I’ve corresponded offline with a couple of other developers, but it seemed like I should go slightly more public with this.
Don’t know if this is still the case in AAX, but in RTAS you need to add some preprocessor define to avoid iterator debugging
Check the README
Otherwise it lead to some crashes
[quote=“otristan”]Don’t know if this is still the case in AAX, but in RTAS you need to add some preprocessor define to avoid iterator debugging
Check the README
Thanks. That appears to be only for Visual Studio and isn’t mentioned in the AAX documentation anywhere. So I don’t think that’s it.
I do have another suspicion that is supported by some evidence. This particular 64-bit DAW (you can guess what it is, but I don’t want this thread to get picked up by search engines) does some caching of executables. That’s even true when you delete all copies of a plugin. This means that you have to be very careful about any static values that might be initialized by the object loader (things like IsInitted flags, counters and such). It is very possible that you can reload a plugin to find those statics have the last value written to them–not the initial value. This is dangerous as hell. So you have to make sure that destructors are meticulous in resetting values. You can argue that’s good practice (indeed it is), but most of us have relied on object loaders to make sure statics and globals are properly initted. They are initted when they’re loaded, but that load might happen only once. It seems that the DAW is keeping the executable in memory even after the plugin is dismissed.
Virtually all of the crashes I’m seeing now happen in the callbacks provided by the Juce AAX wrapper. They’re not deep in the code–they’re right there in the callbacks. So I’m wondering if there are residual values in the wrapper that need cleaning up.
Found a partial solution! I’ve been working offline with Yair about this one. He discovered that setting [color=#0000FF]JucePlugin_WantsMidiInput[/color] to 1 results in a stable build. There’s not much difference inside the wrapper as the result of that flag, but it’s enough. Both of us are dealing with some deadlines, so the underlying cause can’t be dealt with immediately (unless someone else wants to take a crack at it). But in the short run, say you want MIDI–whether you want it or not.
Ok I now have a fix that seems to work without adding MIDI input to plugins
Basically it seems that just having midiNodeIn and midiNodeOut in JUCEAlgorithmContext causes gaps in the used JUCEAlgorithmIDs and that causes things to break (crash).
Without this fix, building a Juce demo plugin with MIDI disabled causes it to crash PT, and with this fix everything works fine so far.
Wow… Who’d have thought that gaps in the structure would make it crash. Scary! Thanks - I’ll get something checked-in for that asap!
I’ve just had this verified by the DAW manufacturer (who shall remain nameless, but you all know who it is). They employ a caching strategy in their 64-bit program that does pretty much what I expected. This means that you have to pay careful attention to the final state of any static data–it has a good chance of being the startup state next time around.
If I remember correctly Digital Performer does the same thing FWIW