Why do developers hate 64-bit Vegas?

Lowtaxico wrote on 9/4/2009, 9:17 AM
I'm unfortunately aware of Sony's questionable stance regarding third party plugin support, especially since the release of Vegas 9 eliminated the functionality of the few third party choices us users had. I absolutely love Boris Red, and think it's one of the greatest plugins to ever support Vegas, but it's unusable on my 64-bit version of Vegas 9.

Does Sony have any plans on ever encouraging more developers to create plugins for Vegas, particularly 64-bit versions? Since I'm working in 64-bit 9, I have to do all my effects in the standalone version of Red, which requires me to render an uncompressed avi in Vegas, importing it into Red, creating the effects, and then exporting it as another uncompressed avi. Additionally, since Red is a 32-bit app, I have a difficult time rendering any 1080i / 60fps footage longer than 10 seconds. I'm assuming this is due to a memory limitation or leak in Red.

So has Sony ever detailed any timelines or even a broad philosophy for dealing with third party devs? Are there any other NLEs out there which have less third party apps than Vegas? I think Vegas has a ton of potential, and it has by far the greatest workflow environment I've used, but it seems to be hampered by its lack of support.

Comments

ScorpioProd wrote on 9/4/2009, 11:38 AM
I'm not sure what Sony could do to change this... I mean, it's not like they pay the third-party developers...

I was just talking to Satish about a 64-bit version of his Frameserver that many of us use from Vegas out to MPEG encoders and other applications. He said there haven't been a lot of requests for 64-bit support, so it's way down his list of things to do and not something coming soon.

So, with that, I'll be staying 32-bit for a while.
Tech Diver wrote on 9/4/2009, 12:14 PM
I'm running Vista 64 with the 32-bit version of Vegas. I am also a Boris Red user and have accepted the fact that it will probably be a few years before we see the majority of plugin developers leveraging 64 bit platforms.

Based on the current greater number of 32 bit plaforms in the field and the fact that the economy is in a major recession, I really don't see much incentive for product developers to change the focus of their workforce at this time.

Peter
Lowtaxico wrote on 9/4/2009, 1:01 PM
"Based on the current greater number of 32 bit plaforms in the field and the fact that the economy is in a major recession, I really don't see much incentive for product developers to change the focus of their workforce at this time."

I guess I'm sort of confused at the lack of 64-bit support in general, particularly in the areas of pro / prosumer audio and video. The 32-bit memory restrictions have been a huge limiting factor in any number of projects, so you'd think there's be a real pent up demand for 64-bit apps and plugins that take advantage of all that freely available RAM.

While I understand we're in a recession and all that, I was always under the impression that a good, stable, 64-bit NLE with plenty of third party support would be a dream for a lot of folks who spend a lot of money on this type of software. Since more and more camcorders are able to shoot in high def, I would imagine the demand would be greater than ever. Is 64-bit architecture simply too overwhelming to code for?
Tech Diver wrote on 9/4/2009, 1:51 PM
"Is 64-bit architecture simply too overwhelming to code for?"

64 bit architecture is no harder to implement than 32. It's just a major effort to change existing applications from one form to another. I remember the pain involved years ago changing 16 bit products to 32 bits and the resulting instability that followed.

Also, you can't abandon your existing customer base and must maintain two flavors of your software product. It will take twice as long to do quality assurance, which means it costs more to produce and release the product than before.

Though this article is about three years old, it still gives insight on the programming differences between the two environments:
http://msdn.microsoft.com/en-us/magazine/cc300794.aspx

Peter
Himanshu wrote on 9/4/2009, 3:52 PM
Generally speaking there are two issues porting an existing 32-bit plug-in to a 64-bit environment (assuming they have a 64-bit environment to build/test/run on):

1. Lack of updated documentation as far as the Video PIDK (aka SDK) goes. The current release is several years old and makes no mention of 64-bit development specifics. SCS says there should be a new PIDK sometime soon, but 64-bit plug-ins can be created with the existing SDK, so this is not a show-stopper.

2. Lack of developer knowledge on porting a 32-bit application (in this case, plug-in) to 64-bits. In several cases, especially simpler plug-ins, this is trivial to do and may not even require major code changes. For more complex cases, it may require an understanding of porting code, but all this information is available on MSDN and several reputable programming sites. It also helps to have the latest development tools which make it easier to generate 64-bit applications.

Both of these are one-time hurdles that if a developer really wanted to spend time/money on it, they would. I don't believe SCS has a responsibility to port any 3rd party apps, but IMO updated SDK documentation is long overdue.