In answer to your question JR, no I wouldn't. =)

And just to voice agreement with what Robert said, as I stated earlier I also will not/cannot use the 64 bit version till I have all my plugins working. I opened a couple projects in 8.1 and noticed immediately that it was indeed much faster in many regards, tinkered for about 5 minutes, and that's about it and about all it will be for awhile. While I don't think it's fair to put down Sony, third party developers, or feign a false sense of entitlement, its defiantly a drag now that the big much anticipated release has come and gone that I'm still waiting and most likely will be for awhile until I can take advantage of the improvements.

- Ray
Some of my stuff on Vimeo
www.undergroundplanet.com

Be it in the interests of profiteering or otherwise, I personally think that commerical developers can be very misleading about the difficulty involved in transitioning their software to 64 bit. For the most part, I am not aware of there being any fundamental differences in the way Windows works when it is addressing 32bit or 64bit code. The bulk of the work is done in the compiler.

If Vegas 64bit had been truely a strongly developed piece of software, it would have actually been redesigned for the way the 64bit architecture works. I think the biggest speed increases would have been gained from optomising the multi-thread handling for the increased RAM availible to the application.

In the actual code base, a lot of the new 64 bit stuff would probably be focused around memory and processor handling. These procedures may be original code, but they would most likely be tucked off into their own little procedures. It is not like you would have to recode the whole package.

And that is assuming that the compiler and Windows 64bit API's and kernals do not handle this automatically. The fact is, if you took the Vista 32bit code, you could probably compile it to 64bit compatible code pretty easily, and get it to take advantage of the basic memory and multi-core benfits of 64bit systems with very little extra code.

I think the Vegas 64 bit package sounds like it has been ported with very little extra development put in place. If there were legacy wrappers and new 64bit centric features then I might think it took a little extra effort. To me this looks like Vegas 32bit compiled with a tiny bit of extra code and a /64bit switch.

The bluff on this is called by open source applications such as VirtualDub which compile to 32bit and 64bit from very similar code. That is not to mentioning programs that compile to a wide range completely different platforms with very conservative amounts of platform specific code in the codebase.

"Windows Vista 64 and Windows XP 64 are both 64bit systems with support for 32bit code using the WOW layer."

You're not getting what I am saying. WOW64 allows 32bit programs to be run within a shell AT THE 32 BIT RATE This would defeat the entire purpose of Vegas 64. If you want to run 32 bit plugins then Sony has an answer for you and it's called Sony Vegas Pro 8c

In the mean time, it is up to the plugin writers to play catch-up.

Am I coming from the fabled land of the orange banana tree here? I do not know how much simpler I can state this.

There obviously is a practical need, be it short term or otherwise, to be able to run 32bit plugins from with Vegas 64bit. As it currently stands a lot of plugins appear to be incompatible. Thus you lose a lot of features from your editing suite. If you wish to transition a project that uses 32bit plugins and there is no 64bit version available you are therefore stuffed.

Also, if you start a new project, you will probably at some point be keen to use some of the features of the 32bit plugins which you paid for. If you can not use them then you are more likely to continue to work with Vegas 32bit.

Hence as I said, not including a transparent 32bit plugin wrapper in the 64bit architecture is very short sighted.

Transistion is not about takign a blind leap into a new platform, it is a about carefully managed switch to a new system. Did it defeat the point of the Mac OSX platform switching to Intel processors to include emulation for PowerPC processors? No, because it offered an essential bridge while software was made availible in dual binaries. The functions were the most important things. If you decrease the functionality of your software on a new platform, who in their right mind is going to switch?

As I said, a wrapper would probably be required to maintain this functionality, and it would not be difficult to integrate this into the Vegas 64 bit architecture. It may mean that Vegas 64 needs to run a surrogate 32bit task in order to achieve that, but it is without doubt doable and desirable.

And what is more, it does not defeat the point of 64bit because the core program still has all the benefits of running on 64bit architecture, as do 64bit compiled plugins. Also the 32 bit plugins will have access to more memory within it's virtual allocation within the main 64bit memory pool.

So it seems to me there are a whole raft of benefits.

Or, you could wait with you hands on your backside for that magic day when all the plugins you need are available, or compromise your project and not use the plugins you paid for, or even more adventurously, stick with the 32bit version.

Yes, great thinking there. That is how Beeching got his axe.

"There obviously is a practical need, be it short term or otherwise, to be able to run 32bit plugins from with Vegas 64bit. As it currently stands a lot of plugins appear to be incompatible."

There is no practice need what so ever. If you have 8.1 then that means you must have 8c (unless you actually PURCHASED 8.1.... let's have a show of hands.... how many purchased??)

Unlike Vista 32 and 64.... you CAN run both 8c and 8.1 together on the same machine. So what's the problem?? Are you telling me that you can no longer access your plugins??

I for one DON'T want Vegas 64 mucked up with a lot of backwards computability stuff possibly causing MORE problems.... and under the circumstances there is no need. Heck.... if I close my eyes I can just see all the yelling and screaming that Sony would have to endure should a 32bit plugin function wrong! Continue to run 8c if you plan on using plugins until the REAL culprits... (the writers of the various plugins) get their butts in gear and get some proper plugins out. And that question of "paid plugins"..... let's see if the plugin writers are going to be as noble as Sony and hand the 64 bit upgrades out for free..... I'm betting.... NO.

And BTW.... It's been no big secret for a LONG time now that Sony would be outputting a 64 bit program.... so why aren't these plugin writers a bit better prepared??

Robert... I COMPLETELY and TOTALLY disagree with you. I do NOT want 32 bit plugins in my Vegas64.... and furthermore.... I think it's a BAD idea. There is simply no way that you will convince me otherwise. The editing world is complicated enough without adding that possibly large headache.

"And what is more, it does not defeat the point of 64bit because the core program still has all the benefits of running on 64bit architecture, as do 64bit compiled plugins."
And this is wrong. You can't operate in BOTH the 64 and 32 bit world at the same time. If you get into 32bit plugins then the entire process (rendering process) must be handled at a 32bit rate.

Well, I must be mad because I want whatever plugins I need to work in Vegas 64bit. If they offer backwards compatibilty then it means I can get the benefits of the plugins and the program core that are already 64bit and still have the features of the 32bit plugins that have not yet been compiled for 64bit.

Again, TRANISTION is the key word. That does not mean leaping into a magical ready made world where all the software is delivered to the new platform over night. It means providing provisons for the user to make their way comfortably from one system to the other. it is about plannign and intergrating the new platform into your systems and workflows. OK, the 64bit version of my favorite plugin might not be available yet, but we can make the most of our hardware investment by using the features that do support it, and we can TRANISITION and take advantage of the other parts as the right software becomes available.

Of course bearing in mind that Vegas is a preset heavy system that has absolutely no facility for carrying forward presents from one major update to the next, I am not really suprised they have failed in regard to transitioning.

Also, it is a little shoddy to start pointing fingers at the third party developers. Would it make sense for them to develop for a platform for which there has been no release date for the last year? I mean, the first word I got of a release date was yesterday, and that was only because it had been released. Would a sensible company start spending time and money on developing the latest version of their software with 64bit compatibility in mind when that release may be defunct by the time the host application that can run it finally emerges? I would not be suprised if the first they heard about the release was yesterday as well.

And another thing, why release on a Friday, when support is going to be closed down for the weekend? Opps, hang on, coudl it be because a big trade show started then? Maybe this might be why this is yet another half baked release...

EDIT:
I'll add that I really do not think it would be a support issue. If they were worried about such things they would not issue with dopey unreliable updates. They must know their API inside and out now, seeign as they never update it. It should be easy to write a wrapper, bearing in mind the format of the data fed to the host from 32bit and 64 bit plugins will most likely be identical.

"Also, it is a little shoddy to start pointing fingers at the third party developers"
So pointing fingers at Sony makes more sense right?? Why is it Sony's responsibility to make sure third party plugins work???

"Again, TRANSITION is the key word. "
They have already thought of transition. The projects are backwards compatible. Just exactly how much is Sony supposed to be responsible for? Who's going to pay Sony for testing all these third party plugins?? Is Sony going to make any money from it? What 3rd party plugins should they test? Do we follow YOUR list of recommended plugins or someone else's? Or maybe they should scour the internet for EVERY possible Vegas plugin and test them all. How long do you think that would take and how much money do you think they would lose in the process?

Bottom line.... Sony is not responsible for 3rd party plugins. It's up to the developer of that plugin to make sure it works.

Blink3times

I really don't see what the problem is. All I've said is that my requirement is that I would want to run 32bit plugins, and I have explained why. I do not understand how you can think that my requirment is so completely daft and irrelevant. I am fairly sure it would be the requirement of a lot of other people too.

However, what you seem to be arguing is that my requirment is irrational, and to be disatisfied that the software fails to meet that requirement is also irrational and maybe even stupid.

My argument is that the software shoudl be written with support for legacy projects and 3rd party products, and should not lead to the immediate scrapping of your entire third party plug in suite.

Sony's treatment of the existing userbase is very poor. There is no continuity between versions in terms of setup and presets, and now you can wipe out your third party plugin collection. A wrapper would not have been hard to code and an obvious boon to both the userbase and developers.

More and more with Vegas I keep seeing the mistakes that led to the end of the last great video system for the masses, the Amiga. The developers for that platform neglected it, made terrible decisions in regards to developing new systems and in the end it fell behind and was abandoned. Vegas is heading the same way.

"My argument is that the software shoudl be written with support for legacy projects and 3rd party products, and should not lead to the immediate scrapping of your entire third party plug in suite."

Your argument is baseless because Sony was never responsible for 3rd party plugins in the first place. Sony didn't "scrap" all YOUR plugins... because they were never THEIRS to "scrap" in the first place.

You didn't answer my questions. Why should Sony be responsible for 3rd party programs that aren't theirs and they're not making any money from? What plugins should Sony be testing... the ones YOU'RE using? What if I'm not using YOUR list of plugins... should I be mad that Sony is paying attention to you and not me?

Sony never wrote their software to accommodate 3rd party plugins (unless paid to do so). It has always been that 3rd party developers have written the software to fit Sony (as it should be). Why should it change all of a sudden?

Guys, interesting stuff. A couple of points. A 64 bit program can call 32 bit libraries, etc.. In fact, Vegas 8.1 does it. SCS has no choice, since the Main Concept codecs which they license are still 32 bit. The problem is that 3rd party codecs and plug-ins (not installed by Vegas 8.1) are not visible to the proxy that SCS uses to call 32 bit routines. Take a look at all the Vegas subfolders. You will see files that allow 32 bit libraries, etc. to be utilized. Run Process Explorer, the replacement for the Windows Task Manager. It will show you that Vegas is 64 bit, but that it also has spawning 32 bit processes, such as FileIOSurrogate.exe. It's not the way you are supposed to do it (a 64 bit program should be 100% 64 bit), but the mechanism (called "thunking") has been around since 32 bit programs on Windows 95 needed to call 16 bit code.

I'm not sure why SCS rushed to put out a hybrid 64 bit version of Vegas. I just noticed earlier today, that when I tried to open either mt2 and AVCHD files, 8.1 couldn't open them at all. I reinstalled 8.1 and then it worked fine again. That's not encouraging. I've given up on 8.1 altogether. It's basically an open beta and we are the guinea pigs (without lipstick).

"A 64 bit program can call 32 bit libraries"
I don't think anybody is debating that. You can easily run 32 bit systems within a 64 bit atmosphere, but it's not functioning at a 64 bit rate anymore.... that's the issue.

As for 8.1 not being quite totally ready.... I've been saying that for months. If you look in previous posts of mine on this issue I've suggested Vegas 64 will not be usable on any serious level for at LEAST the first few patches. Vegas 7 wasn't really ready until version d. Vegas 8 wasn't really ready until version c (some would argue even d.... if there is one). My guess for Vegas64..... maybe another year.

I noticed the Surrogate file running earlier today while doing speed tests. Not sure either why they have chosen to do it this way (deadlines and promises most likely)... but one thing is for sure.... 8.1 IS faster than 8c... no 2 ways about it.

Amazingly, I agree with Blink. Back in a previous life, I wrote software for a living and it is simply impossible to catch every bug or possible problem using a beta test program, no matter how big the beta test program was. All us Vegas "old timers" know the drill; they release a new X.0 version of Vegas and a couple of weeks later, the X.0b version comes out that solves a lot of issues that just couldn't be detected until it was released to the general user base.

I also agree with Blink in that 8.1 is blazingly fast. For projects which don't require anything but the tools available in Vegas itself, I'll be doing them in 8.1. I've been working in it for a few days now and it's really pretty solid for a first release. (And did we mention it's fast?) I'm happy.

I have no doubt that Blu-ray GUI bug would have been caught in a beta. I really think that particular bug shows just how sloppy the development of this package has been. That is a really big bug that would have been trapped within hours if this current release would have been a Beta and there was opportunity for the feedback to be acted on.

What seems to happen is that the package moves to a certain point, they issue a closed Beta, and then instead of having a period of time where they consolidate the code based on the feedback, they just keep on pushing forwards. The means you always get the same standard of buggy code. Then before they do the proper release they should let the beta testers have a release candidate which is identical to the version they intend to release.

I don't know how many times I can write "Transition" in a thread, but I am sure there are more people than not that would have found support for 32bit plugins very useful, if not essential. Obviously running a few plugins in 32bit modes does not destroy the benefit of the rest of the code working in 64bit. It has been pointed out that Vegas 64bit actually appears to use great chunks of surrogate 32bit tasks for things that should have been coded into the core of the program anyway, and it still achieves a large speed improvement.

The point of 32bit plugin support is that people want it. Not Blink3times, but most of the rest. Of course, if it is implemented, Blink3Times does not need to use it. So he can snigger at the rest of us working in 64bit with bits of 32bit code bolted on, and he can work in 64bit with bits of 32bit code bolted on (just not the plugin bit).

"The point of 32bit plugin support is that people want it. Not Blink3times, but most of the rest. "

I keep pointing out to you that 32bit support is already available.... it's called Vegas Pro 8c. This is a 64 bit platform and if you add 32 bit support then 3rd party developers have no reason to upgrade their software..... and most likely WON'T. We will continue to live in the 32bit world, and these plugins will slow us down. (My guess is that they'll find a way around it anyway). If they want to make money, let them rebuild the plugs in a 64 bit platform.

I have A LOT of plugins and feel quite naked without them, but what I want MORE is a true 64 bit system..... not some 1/2 baked apple pie so at the end of the day Robert.... you are quite correct..... I DO NOT want 32 bit support.

Blink3times,

What exactly is your problem with this idea? Is the crux of it actually that you do not think the developers will produce 64bit versions if support for 32bitr versions are available? Because only a short sighted developer would think that way. Also there are also plugins that are no longer being developed and for legacy purposes compatibility is very important.

The overhead of 32bit software running on WOW is very low. I just think your argument for keeping this feature out of the software is pretty facile.

1) There is already 32bit code in the core of the host software
2) The mature approach to transition is that you make a gradual change.
3) It is necessary for those of us who have a practical need to use their existing suite while 64bit versions are not available. Some of us have working pressures, we make an investments in plugins and we need to use them.
4) We will get a measurable and definite benefit from the 64bit element in spite of the parts that remain 32bit.

This chunter about "the 32bit version being the version with 32bit support" it nonsense. As I said, we have made an investment in 64bit hardware and we want to exploit the value in that as soon as possible. The performance gains from the core will be a big benefit in spite of 32 bit legacy support.

Legacy support is a critically important part of developing a new platform. I need it. Simple as that. If you are so fussy about wanting a "true 64bit system" then don't use Vegas 64bit, because some of its core operations are still 32bit!!!

"Because only a short sighted developer would think that way."

I have already told you the problem with this idea. 3rd party developers will not be re-writing their software anytime soon if there is no need and I don't care how low the WOW overhead is. A 32bit plugin will operate at a 32 bit rate which is NOT what is wanted.

Vista 64 (even XP64) has been out for how long??? Look in your WOW folder and see how many files are in it. The immense size of this folder will give you an indication of how fast and furious developers are re-writing their software in a 64 bit nature. In other words they are not....... there is no need. WOW functions quite well....... a little TOO well. Well enough so that that I'm sitting here A YEAR after buying visat64.... and wondering why!?!

Ha ha ha, how could the developers develop for it if Sony were not even giving them development versions? It seems Vaast for one had no access to the software. As I said before, Sony did not seem to tell anyone when the software was coming out until the day it came out!

What is more, I really do not think coding the plugins for 64bit is going to be that big a deal. For a lot of plugins it is going to come down to a little bit of tweaking and getting their compilers to produce 64bit code.

I want the benefit from the new system when I can get it, but functionality will always take the highest priority. Now if you are a developer and everybody is sitting about on the 32bit versions waiting, that means nobody is using the 64bit version. So where is the motivation for developing for it there? Transition mate, transition.

But you have your approach and I have mine.

P.S.

I will also point out that Windows 64 bit platforms are still very young. Part of the reason there is a lot of 32bit code still in use is because very few people are using the platform in spite of nearly all new processors having 64bit instruction sets. You can only get people developing for it when there is any tangible return. This is why it is important to get people using Vista 64bit as soon as possible.

"Ha ha ha, how could the developers develop for it if Sony were not even giving them development versions?"

Which came first... the chicken or the egg? Answer that question and I believe you will be able to apply it here.

The point is that 8.1 is out and unlike vista, Sony appears NOT to have given 3rd party writers a back door to escape from..... and I say..... GOOD. Now, let's see how many actually re-write the software to match, and how many look for a back door.

Interesting.... I was reading HV20.com and here's what Eugenia (the moderator) had to say:

"8.1 is a 64bit version. MOST of the 32bit third party plugins and SOME 32bit codecs will not be able to work with the 64bit version of Vegas. This is normal.

..... and I agree completely.

This is complete madness. How you complain that you only want software that is fully 64bit and have a go at third party developers, when it appears that Sony didn't even give one of the main third party developers access to develop on the platform prior to release? Sony have done everything they needed to to make sure that their product arrived with no third party support.

The long quote you made pretty much says that we should not expect to have any worthwhile software for ages. So how do you get the benefit of the 64bit core? Who is going to transition to it? What harm does it do to have 32bit plugin support?

I just do not know why you will not acknowledge that there is a benefit to having even just the host running in 64bit. I can not make it any simpler, functionality comes first. Sony need to support us in the transition. People are not going to be greatly motivated to make the switch if they are going to be starting from scratch once again. Professionals are not going to be able to use this top of the range application if it does not have the functionality of the earlier versions that.

But anyway, Blink3times, I do hope you are not going to use the evil 32bit Vegas in 64bit wolves clothing. Mu ha ha ha, EVIL 64 bit/32 bit VEGAS MU HA HA HA HA. I VANT TO SUCK YOUR 64 BITS! MU HA HA HA HA...

...AH HA HA AAAAHHH HHAAAARGGH HHHHHAAAAAARRR!!!!!

"Sony have done everything they needed to to make sure that their product arrived with no third party support."
According to Eugenia in the above quote, Sony has done NOTHING more or less than others that have gone 64bit. It is only in YOUR head that they have done a tremendous wrong.

"So how do you get the benefit of the 64bit core? "
EXACTLY. If SOny provides 32bit plugin support then the chances are great that we will NEVER get true benefit from 64 bits.... nobody will bother re-writing... and the proof of that is in your Vista WOW folder.... which you keep refusing to acknowledge.

"Sony need to support us in the transition"
I suppose they should come and hold your hand while you cross the street too?

"EVIL 64 bit/32 bit VEGAS MU HA HA HA HA. I VANT TO SUCK YOUR 64 BITS! MU HA HA HA HA...
Yes... I agree... this is complete madness.... not to mention silly. Sony has provided into your rather ungrateful hands, a glimps of the future.... COMPLETELY free of additional charge.... I may be wrong but I doubt we'll get that from the 3rd party developers. But you go ahead and look a gift-horse in the mouth if you wish.... some people just simply are never satisfied no matter what is done.

Are you really blinking or do you have your eyes completely shut? I quite clearly said that you will expect to have some 32bit code hang over for a why. TRANSITIONING! TRANSITIONING! TRANSITIONING! The only way you can expect to use to the 64bit core usefully it to have some bits propped up with 32bit in the short to medium term. You even say it yourself in your own post! If you wait for it to be 32bit code free you will probably have to wait for the 128bit version! I mean Vista 64bit is the first version o drop 16bit support as far as I am aware...

Ha ha, thanks for the glimpse into the future Sony, how kind of you. A piece of rather limited use software.

Once again i shall point out, you are getting on the back of third party developers, but if key players such as Vasst did not even have a copy of the software prior to release, is it really fair to say they have been dragging their heals on it? For not having software ready for a piece of software they never had and had no notoficiation of the release date for?

But anyway, I bid you and your several bags of frogs well.

You do have some funny arguments blink. Most of them with little or no thought behind them. Let's replace Sony with another company in your chain of arguments here... Please note, a piece of software as complex as Vegas is not really just an application, it is an entire environment where Sony and third party tools live and run.

So, let's transcode this: Sony was never responsible for 3rd party plugins in the first place
To this: Microsoft was never responsible for 3rd party applications in the first place

And this: Why should Sony be responsible for 3rd party programs that aren't theirs and they're not making any money from?
To this: Why should Microsoft be responsible for 3rd party programs that aren't theirs and they're not making any money from?

In addition, your statement "Sony never wrote their software to accommodate 3rd party plugins" is patently absurd. Of course Sony wrote the software to accommodate plugins. That is what the plugin APIs are for.

Any software development company that develops software that invites third parties to develop software that runs on top of their have to take compatibility into consideration. This is normal. It is perfectly possible to write a compatibility wrapper so that functionality from 32 bit DLLs can be used from a 64 bit application. Many have, and I can write one for you if you want to. It is also something Sony should have done. It was in fact their responsibility.

It is, of course, the responsibility of third party developers to by-and-by upgrade their plugins to a 64 bit architecture, but given the fact that Sony was horrendously late with Vegas (according to Sony's own statements earlier) moving your plugin to 64 bit Vegas would have be tantamount to suicide in a business where there is any amount of competition.

I have to say that I find this to be yet another indication of the problems we so often see SCS plagued by. There appears to be no business related product management in SCS at the moment and that is bad news for all of us.