Quote:
Originally Posted by Berni
When access released the TI all those years ago it's biggest user base was PC/Cubase user's so VST was the first format to be supported followed by Audio units a little later & finally RTAS much later so obviously the VST format has had a lot more development than the other formats. I'm convinced that they are still developing the RTAS format as it consistently runs like crap no matter what I do & yet the VST on the same set up works far better.
Since then however Cubase is not top dog anymore or PC's for that matter IMHO. Programs like this need constant development & upgrades to keep up with faster computers, new OS's & upgrades to the DAW's it is supposed to work in & lets face it access are simply not doing this. OS5 is still is still a long way off what it should be & it has taken over a year to get this far! Pro tools have adopted a new plugin standard AAX that a lot of my plugin's now use. Try & get an answer out of access when there plugin will be ready, LOl.
|
Understood what you mean about Cubase not being top dog anymore, but because Steinberg basically standardized technologies like VST plugins, ASIO drivers, etc., my fear is that to some extent the QA process of individual plugins relies on Cubase as a baseline and testing priority compared to other DAWs (i.e. if it works in Cubase, who defines the VST standard, but doesn't work in such-and-such DAW then the problem must be with the DAW and therefore we're not going to spend money shimming and kludging the code to overcome every possible hurdles). It's not necessarily an accurate perspective in all cases, but it is a mentality that software development and QA shops often fall back to because of the exponentially increasing cost of making sure something works on every host all of the time.
The same thing exists for example with Android devices. There are thousands of possible Android devices, and making sure that an app works on all of them would be cost prohibitive. So, you just target the Google Nexus line (the reference model from the company that creates the OS itself), test it on maybe 2 or 3 of the best-selling clones, and call it a day. Otherwise the cost of adding individual code shims to make things perfect on all devices becomes something like X^Y where X is the dollar cost and Y is the number of uniquely behaving devices (the reason for non-linear cost model is a complex discussion in itself). Not only will some of the non-reference models get neglected, but during the products lifecycle, there is a high likelihood that the amount of time given to the best-selling non-reference models will decline (because sales will not justify the ongoing cost to the company, who of course is always in the game for profit rather than goodwill).
I can't say for sure that's how the testing works at Access with regard to VC, but that's how it works at most places I've worked at that deal with the scenario. Even back in the days of mostly fat-client development and Win32 apps, the QA folks can basically test the software on a vanilla Windows install, Windows with all service packs and patches, etc and maybe a few commonly used apps. But inevitably you run into some guy going "hey your shit doesn't work!" and it was often (back then) because he installed some obscure software that screwed up his registry or some file dependencies, or maybe he had malware etc. It's just impossible to test every possible combination, so when you consider the number of different DAWs its a similar scenario.
I once saw a plug-in that worked on most DAWs except FLS, and it froze up in FL because of an oversight with multi-threading by the VST developer. FL was following the rules of Steinberg's VST standard well enough, but because the dev didn't test in the FL environment, he didn't catch the bug until much later. Coding to a standard does not guarantee every environment that adheres to that standard will work in all cases -- they still take extensive testing, which of course costs human time and that can get really expensive really quickly.
So, all of this is not to say that newer and better plugin architectures don't exist. The real question I guess is simply whether Access uses Cubase as a priority test platform for the VST (and if not, why does it seem to work best on it)?