Lawyers? I'd suggest it's far too late for that.

Graham

Gary's comment is right on.

Essentially the real value of VegasPro as a software progression schema has a very high value in the scripting language that was adopted. The same could be said for DVDArchitectPro - but that particular software suffered greatly because there was very little deployment of the workings.

So back to square one, we are essentially looking at VegasPro being gutted by Magix acquisition and henceforth probably not be a player.

I don't understand how the people who are supposed to be looking at these matters, just seem to overlook the issues. Pure absolutely pure.. incompetence!

This whole buying doesnt sit well with me at all, what with all the "pay for v13 to get v14 free" sounds alot like "get Windows 10 free [however all your printers and cameras wont work with it, BUT IT WAS FREE]".

I still have a box v13 thats never been installed (waiting on deploying the new server / PC), and i dont like there new "upgrade" thing, works for a year, if you need to re-install you need to pay AGAIN.

I am sure with this scripting issue alot will be looking at new software, unless things like scripting is resolved.

I use Vegas as just a video editing and production, i dont use scripting (that i know of, unless some plugins use it)....

Poor form - just get permission from whoever is needed to continue to use the same namespace. There are hundreds of scripts out there. In one fell swoop you'll lose a chunk of the key customer's reason for loyalty. Vegas is three years behind the competition.

Obviously, this has significant impact which is why I've brought it up early. I have not lightly made the decision to proceed in this manner. The naming changes are not optional. Addressing them with a change to VEGAS Pro code comes with risk, not the least of which is that it would take developers off of working on desperately needed stability and performance issues that affect all users.

I will follow up soon with more details about exactly what will be happening so that you can formulate your solution plans. You who use simple one-off scripts will be pleased to find out just how easily you can fix this. As has been correctly pointed out in this thread (or the one in the main VEGAS Video forum), those of you who use compiled extensions have a more difficult problem to solve. I believe this community will pull together to help one another solve it.

I've already seen many people (among the very small number who are aware of this disastrous engineering decision) who have said this absolutely kills any chance of them upgrading to Vegas 14 and beyond from earlier versions. Many people simply can not use a Version of Vegas that abandons and tells them it's up to them to solve the cataclysmic impact and potential financial burden that immediate obsolescence of their most powerful 3rd party Scripts and Extensions will bring.

If you look back at the roll out of Vegas v13, you should remember the stink that was caused when v13 did not run all legacy scripts and extensions in its first few releases. What you're talking about is v14 NEVER running any of these.

for GaryRebholz : when you say the "naming space is not going to be an optional consideration" - I think what you meant to say was that "the change was not affordable by Magix and further that those legal rights that remain held are with the intent to kill further exploration of the VegasPro line as a progressive software build. This would appear that whoever held the cards knew exactly what they wanted and Magix acquisition team had no idea. Very poor negotiation form!

Just again to reflect - for the salad days of DVD Architect Pro in its prime - the inclusion of scripting options was a huge bonus that without support by SCS -just fell on its face. Now even though the product is worthwhile and would be worth more if the internal scripting were further enhanced and supported - there is no marketplace left. Such issues can be considered timely - the Magix acquisition team is missing the boat entirely.

As a user, looking forward for more detailed information regarding to script change requirements so we can ensure our owned-scripts can still run.

Here's more information on what will happen:

The scripting namespace for VEGAS Pro 14 changes from “Sony” to “ScriptPortal”. In your scripts, any occurrence of items like “Sony.Vegas” or “Sony.MediaSoftware” must be changed to “ScriptPortal.Vegas” and “ScriptPortal.MediaSoftware”. We chose this namespace (“ScriptPortal”) in order to remove any company branding and thus avoid this problem in the future.

For stand-alone scripts (not a compiled extension), you can easily make this change yourself even without any programming knowledge. Open the script with Notepad (always work on a copy of the script in case you make a mistake) and replace “Sony” with “ScriptPortal”. Save the script with a new filename so that you still have a copy that works in pre-14 versions of VEGAS Pro.

As has been pointed out, if you use extensions (like JohnnyRoy's VASST tools or jetdv's Excalibur and Montage Magic) instead of simple scripts, you are dependent upon the script developer to make these changes and recompile the extension.

Next, any scripts that use Sony branded plugins will also need to change the name from Sony to VEGAS. For example, if a script currently uses "Sony Sharpen", you need to change that script to "VEGAS Sharpen". Again, you can easily do this yourself in Notepad (always work on a copy of the script in case you make a mistake) unless it is a compiled extension in which case the original developer must make the change and recompile.

just knew there would be weirdness with the takeover.
new owner needs to cater to the user.

If you going to come up with some retched change
release a script or program that will automatically convert
all the old scripts to the new namespace.

Dont see a real issue here. Vendors, just recompile your extensions and alter your scripts. Then make them available to clients as v14 versions. Did i miss something? Also, we should be happy to see the back of Sony branding in Vegas after the bad service we got from them. Good riddance i say. Onward and upward!

paul_w, many authors of compiled extensions have "left the building". While some such as Vegasaur will surely update their plugins, others will not want the hassle (especially the authors of free plugins). Others will be difficult to trace.

I agree Nick. Older extensions with lost owners may now become obsolete due to this change. But its not the first time a tool became obsolete due to change. Like Mac Motorola code when they went Intel?. Or 32 bit CPUs when 64 bit only apps like Vegas came out... Maybe its just time to change. Just my opinion of course.. I do understand some would be upset. But i actually see this as progress. hopfully with new extensions, new plugins to replace the old. 10p's worth..

Fred Baumann?

paul_w, so how much money are you willing to spend to pay for each update from each vendor of your favorite Vegas add-ins who now has to create an entirely new version of their program for Vegas v14, and maintain two distinctly different versions of their Vegas extensions and compiled scripts?   After all, there are many thousands of copies of pre Vegas 14 out there with customers who expect to be updated when bug releases or new versions of their favorite extensions and compiled scripts come out. 

It really depends on the level at which you operate. If i were a professional editor and using these add-ins daily, then yes i would invest in the best tools available. If i were just a hobbyist then probably not but then again would it really matter?

Its not an 'entirely different version', no, its a simple edit in source replacing a namespace and re-compile, then package into an installer if needed. I guess an average time for that would be around 10 minutes tops if the toolchain is setup and ready to go. I dont really see much expense in doing this although i do see an opportunity for some companies to abuse it.  Hopefully not.

Gary, I know for Excalibur and Montage Magic, I will release a free Vegas Pro 14 update with no new features. There may, at some point, also be a paid update in the future but it will have more features. And it is likely that future updates will only be 14+. The Excalibur for VP13 I just posted will not work in older versions either because it uses a feature not fount in 12 and older.

Paul, there is more to it than just changing the namespace. How much more will depend on the script. 

Its pretty much 'find and replace' as detailed by GaryRebholz's post above. However, i can't see your source and scripts so you know best. I can only speak from my own experience and this would normally be a trivial task, even for a non experienced programmer. Kudos for the free v14 update though. Hope others follow that.

Paul_w mentions an automated tool to do the conversion. This is very practical, even for already compiled scripts. Someone who intimately knows the structure of the scripting engines could knock this out in an afternoon. This would take care of the extensions for which the original authors are unwilling or unavailable to make the changes.

It should also be pretty easy to write a script that runs unmodified scripts and does the namespace change on the fly, allowing Vegas 14 to run old scripts as-is without modification. This is pretty straight forward stuff for anyone who has written language interpreters and virtual machines. Another bonus of this approach is that it could be taught to run even the old Sonic Foundry scripts, something the Sony versions couldn't do.

Not the end of the world at all, but it may take some time for these tools to become available.

This is very practical, even for already compiled scripts.

I'm no expert but AFAIK you cannot extract the source code from a compiled script ( *.dll).  Once it's been compiled as a script extension, you can not go back to the original source.  If I'm wrong, please someone correct me, and tell me how this can be done. 

 

 

Don't really need to update the code, just the name space table which will be a small section of data within the .DLL file. Inside the code itself will merely be index numbers into the name table which won't need changing. Yes, this sort of programming is old hat now.