Has anyone had any experience loading custom chunk data after switching to JUCE? I’ve asked on the JUCE forums, but want to cover all bases to see if there is a solution to this.
Our existing VST3 (and AU) plug-ins used custom chunk data for reading/writing session information. We have begun migrating to JUCE in our products, but we’ve found an incompatibility with the JUCE VST3 wrapper and our old data. For some reason, the JUCE wrapper does not recognize the chunk data that we’re using. It sees it is not a JUCE chunk, so it tries to fall back on using an IBStream* to help parse the data. But at that point, it returns a null pointer for the IBStream*, and when it sees that, it simply gives up and never even calls our setStateInformation() function. If it at least called that for us, then we could figure out how to handle the old data ourselves. But it just gives up, and our code never gets called.
Has anyone else come across this? Aside from modifying the JUCE SDK’s wrapper code, do you know of any way to get this to work in JUCE?
I know it’s along shot finding an answer here, but I gotta try every possible line of attack here, because deadlines are fast approaching!
I know it is not going to answer your question but I am very curious about your decision to decide to migrate to Juce. What is the motivation exactly? As the author of another vst framework (Jamba GitHub - pongasoft/jamba: A lightweight VST2/3 framework) I am always very interested to understand why people use a specific framework and in particular in your case, it looks like you were already writing plain VST3 plugin so what is “missing” that makes you want to switch?
Using, JUCE, we can code once, compile multiple times, and cover a wide variety of platforms. Previously, we had to write separate AAX code and VST3 code, and then build a separate project in Xcode to “wrap” the VST3 plugin to make an AU version. And we had to write completely distinct code for any dialogs or other platform-specific stuff we wanted to write in order to support both Windows and Mac. Now we can use the JUCE platform, let it generate the projects for Xcode and Visual Studio, and only have one single code base. In addition, we get other platforms supported at no extra cost (such as iOS and Android and stand-alone). While there are some customization issues we’re finding, (as expected with any cross-platform implementation, really), the reduction in my time as a developer has been a real blessing.
Thank you for sharing. That is very informative. I am definitely having similar goals in mind when working on my framework (for example, now jamba let’s you compile a VST3 and AU plugin from the same project, etc…) coming from similar pains writing VST plugins.