Let me clarify the confusion.  There is no way that a utility tool can modify a compiled script or extension written for Sony Vegas to be compatible with Magix Vegas; period.   The code in a compiled dll is converted from source text (like you see in .CS scripts) to intermediate compressed MISL code, so swapping references from one namespace to another, along with changing names of video and audio plug-in is not possible.  And even if it was possible, the larger issue is that compiled scripts and extensions are compiled to make calls into the very specific entry points in the Sony.Vegas DLL to perform all of the scripts actions.  There is no way to know where the same entry points into the Magix Vegas DLL are located, or if they are even compatible with what the older Sony entry points were in the compiled dll.

Oh yes, i'm not saying it wouldn't take a lot of work to cover all the angles, but it is much more possible than most folks are assuming.

I agree, it wouldn't take a lot of work. It would take an excruciatingly, agonizingly, impossibly, infinitely long amount of work.  So don't hold your breath waiting for it to happen.

What I get from this is that Magix is caught between a rock and a hard space: Sony demands that all traces of its branding be wiped from Vegas, even from the internal code that only programmers and 3rd party developers will ever see. I suspect this is a non-negotiable trademark issue, but whatever the legal reason it's an unpleasant reality that Magix developers and end users must both deal with.

This may be a painful change for some users, but isn't this level of communication much better than what we had when Vegas was owned by that other company? Kudos to Gary for sharing this with the user community well in advance of V14's release! I'm not suggesting that we shouldn't vent our frustrations, but I do hope that at the end of the day we will show the Vegas team a little love. I for one look forward to seeing what they will do once this distraction is behind them.

Has this namespace change already happened in V13 build 543? Just wondering if it might be the cause of this problem.

I have quite a pile of Vegas plugins and add-ones acquired over the years. Is there any way to know, easily, whether one or another will run on 14? Other than installing 14 on a "spare" computer and trying out all the plugins there?

Feels like it will be prudent to put off changing to 14 for however long it takes to discover which plugins will or won't work, which ones I can live without in future, etc.

As I understand it, none of them at all will run in V14. But most .js and .cs scripts should be very easy to modify in a text editor.

DLLs would need re-compiling by the vendor, Scripts are just text files and very easy to modify by anyone.

DLLs 'can' be hacked, and namespaces in them altered, however thats a terrible idea and lets hope we dont end up going down that road. Better to work with vendors and get an updated release through the proper channels.

The problem is that there are so many useful scripts not written by commercial vendors than many of us use on a day to day basis--e.g. the Show Event Length script.  Many of these were written many years ago and the author is no longer around.  Another example is the Debugmode Frameserver which many find "essential".  The author is still around but has abandoned the project.  It's anyone's guess whether it will work in V14, but I suspect the answer is "no".  Another example is the original PluralEyes written specifically for Vegas which is vastly superior (IMHO) to the Red Giant version.  I'm sure the current version will be updated, but the original vesion will be "dead".  Unfortunately, that leaves many who will be running both V13 and V14 and many others who simply elect not to upgrade since V13 meets their needs and upgrading will result in lost capability.

As to hacking the DLL's, it would be nice if the new namespace and labels were shorter than the old names. That way the new names could be padded with spaces or nops and the address tables and branch points would not need to be affected. At least that is the way it was in my old hacking days...

As to hacking the DLL's, it would be nice if the new namespace and labels were shorter than the old names.

Unfortunately I think it's too late for that. As we've already been told:

“Sony.Vegas” becomes “ScriptPortal.Vegas”
“Sony.MediaSoftware” becomes “ScriptPortal.MediaSoftware”
"Sony Sharpen" etc. become "VEGAS Sharpen" etc.

Yes, this is an important consideration in deciding whejer or not to upgrade to v14. I understand but may be wrong that the free but very useful Timeline Tools will not be amended by the author who has moved on to other things and guess that this may be true for many other providers, free or not. If we have to pay for some of our existing Plug Ins to be upgraded, much will depend on the cost and I know that I, for one, would find this an important consideration.

Richard

Richard, I'm the author of Timeline Tools.  And yes, at this point I have no immediate plans to produce a second version of the utility to support Magix Vegas v14.   And despite what some people have said here, it is not a trivial task, from a developer, support, and testing standpoint, to produce two side-by-side versions of the same utility that work in two distinctly different environments.  TimeLine Tools is a free program that I wrote to make editing my own video projects simpler.  After using it a while I decided to make it available to others who might appreciate the powerful editing features it brings to Sony Vegas Pro.    Supporting Magix Vegas would mean I'd have to purchase a copy of v14 to use for development and testing.  I'm currently running Vegas v11, and it meets all my editing needs; so the expense of upgrading adds no value to me.   Starting work on a multi-host version of TLT would also require me to ramp up my work on a new development environment, at a time when I've ramped down my work on TLT to the point of only fixing reported bugs.

I'm 66 years old, retired and dealing with health issues from exposure to Agent Orange during my tour in the U.S. Air Force during the Vietnam War.  Further software development on TLT is not that high on my list of priorities.  I only mention this because my situation is just one example of how many of your favorite compiled Vegas scripts and extensions will no longer be supported by people who for their own reasons have made their programs obsolete.   At some point I might consider the possibility of turning over the TLT source code to an open source host.  But I've not yet given it any thought.

Will it be possible to have V13 and V14 on same computer, without messing each version up? So, some projects that need older scripts can still be used on V13, while being able to work in V14 on other newer projects, without the scripts. Concerned that if and when I buy V14 and install, I'm no longer able to use V13 in current form with all my scripts - both bought and free.

zipzap.  Yes you can have multiple different versions of Vegas on the same PC.  However, you can't open a Vegas project authored in a newer version of Vegas from an older Version of Vegas.  So that means you can't do some editing in v14, and then open the project in v13 to some other editing.

zipzap, we don't know yet for sure but I would be astonished if it's not possible to run older versions alongside V14. It has always been possible to run multiple versions in the past without messing each other up.

Gary, V12 and V13 were the exception, and I've been very grateful for it because there are benefits to each version and projects can be opened in either. This backwards compatibility will of course almost certainly end with V14 and the new owner.

I was about to suggest open sourcing TLT but then you raised the possiblity yourself. There's no guarantee anyone would take it up though. I'm still hoping somebody takes up the Frameserver open source code and fix the audio glitches with V13 and take it forward to V14.

Thank you Garry.  I was desperately sorry to hear of your problrms and you should know that my thoughts sre with you.

I can fully understand your reluctance to re-write your excellent Plug In and the loss of this brilliant tool is enough to make me think twice about upgrading to v14.

Is the same likely to be true of AVC Colour and the Fasst tools from Vasst?

Richard

It seems a little vindictive of Sony to demand any trace of their branding is removed from the application, even when it affects the usefulness of the code and their former customers. I can not see the problem of changing the naming conventions and retaining legacy support for the old names. It is like Sony is trying to cripple the appeal of Vegas. Frankly I can not understand why Magix would assent to this. It affects the inherent value of the interlectual property that they have acquired. I've never heard of anything similar happening with any other application. It also does not do much to improve my opinion of Sony, who I always thought treated Vegas in a shabby fashion.

Well, if you use a brand name like "sony" you have to license it.

No company would give it for free for a long time without an attached licensing contract (a brand name has a value, you cannot licence for free=giving it a way).

The only reasonable thing Magix could do is tasking themselves (if the plugin author agrees) to update & rewrite those plugins....or include said functions in VegasPro....

Well, if you use a brand name like "sony" you have to license it.

No company would give it for free for a long time without an attached licensing contract (a brand name has a value, you cannot licence for free=giving it a way).

The only reasonable thing Magix could do is tasking themselves (if the plugin author agrees) to update & rewrite those plugins....or include said functions in VegasPro....

But it is not part of the product's branding, it is part of the command set, and part of the feature set. Sony were not priding themselves on their commands having a 'Sony.' prefix. I can understand them debranding the plugins, and maybe giving the commands alternate names, but if 'Sony' is written into the internal pointers, they should keep legacy support for that. Part of the interlectual property in the software includes those 'Sony' tags. I don't see the legal issue in retaining the legacy support for the command names, and making new standard names. It is just not outward facing branding. Actually, by using the Sony name in a functional way, Sony have put themselves at a disadvantage, as the law in any juristiction is going to be more likely to fall on the side on the practical use of the name by the new code owner. This is as if I wrote a novel and it mentioned Sony in it and then they insisted I was infringing their trademark. They exist in the world and they have put their mark on it, and if they sell on a product, they are selling on the marks they made as well, unless there is a specific commercial agreement to remove them. This is why I suspect Magix's representation have been naive in the negotiations in this regard.

The only other reason I could think this is being done is because it will potentially create a watershed forcing users to upgrade to the later Magix versions of Vegas if they wish to use the newest scripts. But I do not think that is the motivator because they could still do that while retaining backwards compatibility with legacy support for the Sony pointers.