So, updating to VST2.4 is on my list of things to do.
We've got full double-precision processing internally (and have had from day one, because we rock), so it's just adding a double-precision input and output connection to the host. No big deal. Real easy.
Guess what! WRONG!
If you've ever written a VST plugin, you'll know that the SDK is a bit messy... there are a few things that you sort of have to assume, or figure out for yourself... but it's not BAD. It's not TERRIBLE. The sheer number of VST plugins is evidence to that. It's not messy, it's a bit scruffy. Rudeboy like even.
It's hard not to like VST. It has an elegance and minimalism to it. An ill type flow that makes it all groovy.
Steinberg are smartening up. Oh lord no.
So. You need to work on Win64... this means that some things need to change.
No, part of the scruffiness of VST was that everything was just assumed to be 32bit. And, because it was, everything worked, and there was no problem at all.
So, let's have thousands of lines of code, expecting the C type "long". Now, let's change all the functions to use "VstInt32" instead of "long" (to be explicit and mark out what will change between 32bit and 64bit versions).
Because of something that you don't care about, but which is a very very good thing, called "polymorphism" in C++, if you don't remember to change EVERY appropriate instance of "long" to "VstInt32" in the definitions of ALL your functions, then random bits of your plugin will fall off. Literally. Bits you were relying on... like... the UI... will just stop working.
**** WHEN YOU UPGRADE TO VST2.4, GO THROUGH ALL YOUR CLASS DECLARATIONS LINE BY LINE, AND VERIFY THAT THE TYPES ARE CORRECT. USE STEINBERG'S ONES. DO NOT RELY ON THE TYPEDEFS RESOLVING THEMSELVES, BECAUSE THEY WON'T ****
And then, when your code actually compiles again, adding double-precision processing support is a synch! :)
But... factor in a few hours of very careful code review.
We chose to stick with the old VSTGUI, rather than moving up to 3, because our current VSTGUI is heavily tested, and works. Merging the old VSTGUI with the new VST SDK was easy enough... although a bit dodgy in places. You MUST be using QUARTZ if you want to keep the old VSTGUI on mac. This is because the VSTGUI QUARTZ implementation registers a carbon eventhandler, and makes all the mouse and key stuff work by magic. VST has now stopped passing mouse + draw stuff up to the gui, so you wanna be on quartz, or you will probably lose your UI!
But anyways... I'm most of the way through with catching bugs... and I've just got to make everything compile smooth ;)
Hope this helps VST2.4 peeps :)
Subscribe to:
Post Comments (Atom)
2 comments:
Yeah, the upgrade to 2.4 tripped me up quite a bit considering I attempted switching versions in the middle of creating my first vst!
Actually, I think it's about starting somewhere you feel most comfortable.
For me, that's a mac laptop, because:
1- i like macos, and xcode, and find em pretty quick
2- i like lying in bed writing code
3- it's comfy, and easily fast enough
4- built in soundcard and coreaudio means i can test everything by plugging in the appropriate dongle/mbox.
This macbook is ill. I suggest them to everyone. You can support ALL platforms, with just a macbook, bootcamp+parallels (you'll want both, so get a huge hdd), dongles for sequencers, and an mbox for protools. Protools runs fine under bootcamp.
When actually starting a new plug, I tend to try and recycle code as much as I can, so I can hit the ground running. For instance, I can strip the TBK source bare, and have a framework, with obvious points to plug things into, in about 5 minutes ['cause it's ULTRA tidy!!].
For me, personally, I like to start ground-up- get a framework (something that compiles, but does nothing); then add in parameters, get all that crap sorted; then dummy up a UI; then wire in the DSP; then fix the UI, and ship! :)
Reusing old build projects + code is great because you can ensure you get your build settings right first time [which can be a headache otherwise, given that there are about 30 flags that you want to set correctly!].
I start with VST, and that's because I have a couple of smallish bits of code that will compile a VST into an AU or an RTAS. The other way around, is, alas, a lot more tricky.
It's hard to notice which platform you're on with VST nowadays - it just works on either.
Post a Comment