Thanks, but what is recommended in order to keep youru scripts compatible for further versions? And what do you risk/loose by importing both namespaces?

The namespace in the next major release will be different but exactly
what the new namespace will be has not yet been finalized. It will
probably just be Sony.Vegas.

I would recommend just using the SonicFoundry.Vegas namespace for now
and updating your scripts when Vegas 5 is released.

I would recommend just using the SonicFoundry.Vegas namespace for now and updating your scripts when Vegas 5 is released.

Why are you forcing all of us to re-write scripts? I came down pretty hard on Sony (in another forum post) for wasting time changing names, but this is far worse because you are now needlessly causing your customers to waste time just so our scripts say "Sony" instead of "Sonic."

Come on, get real!

I STRONGLY suggest that you keep the old calls in place, in addition to any new calls you want to add in order to be "politically correct." That way, you can satisfy the "suits" at Sony corporate without ticking off your customers. ( ... your customers, I should add, who make your product more valuable by writing scripts, plugins, and providing free support to other customers).

SonyPJM, please send a copy of this to your management.

I can only backup johnmeyer! Changing namespace would be as if you'd stop to open projects of older versions. After all, backward compatibility is a marketing feature as well.

I understand you'd like to have your name visible for the mainstream user, but it is primarily the programmers/developpers/"geeks" that will ever read the contents of scripts - the main part of users will never really write scripts. The only people that really DO read scripts, to whom a marketing effect could take effect, are precisely the ones that will be mostly annoyed about this namespace change. So, marketingwise it would be destructive. On the other hand, by keeping the namespace, you show that you care about your users, and you also show respect to the original creators of tisi great product, which will undoubtly be honoured by the users - legends, you know.

Most script authors have a decent editor that can Search/Replace in files in a folder in a matter of seconds. For experienced users I don't see a problem. People who just download (old) scripts and run them might have trouble though.

I do regret breaking all existing scripts.

The namespace change is not just so that everybody's scripts contain
the text "Sony". Namespaces help prevent naming conflicts in object
types. What if another assembly you're using defines a PlugInNode
class, for example? You need to be able to differentiate them.

The fact that company or organization names are part of namespaces
makes sense in that it carves out a "free domain" coordinated by a
autonomous entity. So I don't think we should go on using SOFO's
domain and I think it would be best to make a clean break.

I completely agree with your assessments. Non-script-writers attempting
to use old scripts is the biggest problem.

I believe that supporting scripts with the SonicFoundry.Vegas would
cost users time in the long run. Vegas would need to do a search &
replace every time a script is run.

Besides the legal issues, if we took the approach of maintaining and
loading both namespaces, I believe it would still cost the user time
(and now RAM too) because the SonicFoundry versions of the classes
would need to wrap the equivalent Sony versions... roughly double the
number of object instances, method calls, garbage collections, etc.

Overall, I'm thinking short-term pain for long-term gain is best.

To Sony:

I do regret breaking all existing scripts.

At the risk of being very impolite, this statement is pretty callous and indicates that you just don't get it.

I can think of no other company that I've dealt with that didn't allow older documents (scripts in this case) to be read by newer versions. As a previous poster noted, it's called backward compatibility.

As to the poster that says I can simply do a search and replace, yes that's true. I have thirty scripts. Probably only about fifteen minutes to do them all (I used to have a tool that would batch search and replace, but I don't know where it is). Then, of course I have to run each script to make sure I didn't break something in the process. Probably another half hour. So, I suppose I can fix the whole mess in an hour or so.

The question is, exactly where is the benefit to me in spending this hour? Why do I have to do this? One hour of my life gone forever, for absolutely no good purpose, and all I get is: "I do regret breaking all existing scripts."

Have you guys and gals at Sofo/Sony really gotten that "corporate?" Are you completely out of touch with what it takes to win in the software market?

Do you want to win?

Needless to say, I won't be writing any more scripts anytime soon.

Humbug.

Overall, I'm thinking short-term pain for long-term gain is best.

I'll vote for speed and simplicity (i.e. maintaining ONE imports instead of two)

Will this change "break" my scripts? Yes.

Will it make them worthless? Absolutely not.

I just need to make the proper updates, let people know where the updated files are, and all is well. While it WILL prevent new scripts from running under previous versions at that point, I don't consider that an issue as they will probably be using new features at that point anyway.

You just end up with two versions:
1) Existing version for Vegas 4.
2) New version whenever the namespace is changed.

While maintaining backward compatibility would be great, sometimes that's too big of a sacrifice.

Perhaps there are legal issues as well.

For a superb editor with great search/replace for multiple files, try www.ultraedit.com.

If anybody would be willing to change them all I don't think it would be too difficult. I don't understand java scripting at all. But, in the perl scripts I use for my web page I had to change a similar line of script in the first line of them all when I switched to a new provider.

If anybody would be wililng to do it, I have all the scripts collected in a single zip file on my family website calderwood.org

They could make the change, send the zip file back to me and I would post them on my site. Feel free to email me if you are interested cbcalderwoodatyahoodotcom

Carson Calderwood

Easily enough to do - expecially in Unix (using the "sed" and "awk" tools provided). Probably take me about 4-5 minutes total.

Another thought is for Sony to create another category on the Sundance Media site for 4.0e (and future) compatible scripts. That way, folks can download the necessary script(s) for their particular version of VV.

If someone has all the scripts downloaded from Sundance, I can easily make the changes and send them back up.

-Ron

Of course, as I noted before, Sony could fix this nonsense (which they created themselves) by simply letting the old calls continue to work. This is what virtually any other software company would have done. I still can't believe they did this, and didn't have the grace to reverse their decision. I am increasingly annoyed by what I perceive as an arrogant attitude that I have picked up, not only in their actions, but in the posts on this board. If prodded, I will be happy to cite examples.

If I sound a little miffed, I am. I am very worried that Sony is about to release DVDA 2.x and that it still will contain a major memory management bug -- something that belies and underlying instability. I hope I am wrong, but I am having difficulty getting answers.

Sony could fix this nonsense (which they created themselves) by simply letting the old calls continue to work.

Yes, they could do this. But at what cost? Extra files installed? Slower run time? Potential calling/naming conflicts? Potential legal conflicts with the Sonic Foundry name? etc....

I prefer the name change. It's NOT a big deal. Besides, there may be OTHER sections of code that need to be changed or should be changed as well. Perhaps a new feature is added that can reduce 40 lines of code to 5! Every script will need to be tested anyway. That one line change is NOT a big deal in the grand scheme of things.

Ron, it sounds from your post that you didn't see mine, sorry if you did, but I have collected every script from all known sites and bundled them into one zip file. Just check it out at my family web site www.calderwood.org
thanks,
Carson Calderwood

OOPS - just saw your msg Carson. I will work on these tonight when I get a free moment. Should not take too long. How can I send you the new "zip" file?

-Ron

Yes, they could do this. But at what cost? Extra files installed? Slower run time? Potential calling/naming conflicts? Potential legal conflicts with the Sonic Foundry name? etc....

Ed, I usually agree with you on everything, but on this I think you are trying to defend the indefensible. None of the things you mention are likely to be a problem. I know this because virtually every other development environment has evolved and changed the way things are declared. They always offer either an upgrade tool that will automatically make the changes for you, or they "grandfather" the old calls and still let them work. For instance, I can still run old "Wordbasic" macros in my Word 2002, even though Microsoft dropped support for Wordbasic almost a decade ago in favor of Visual Basic for Applications (VBA).

I especially get mad because this Sony switchover was done (along with the useless 4.0e release) simply to satisfy "Sony corporate." This took time away from development on 5.x. There is absolutely no legal reason why this had to be done. You don't agree? In defense of my argument, let me note that many companies allow an existing brand to exist for a long time before switching to the corporate brand. IBM bought Lotus, but didn't change it to IBM 1-2-3. I could give hundreds of other examples.

Sonic Foundry was not a brand to be ashamed of, and even the confusion with Sonic Solutions was not necessarily a bad thing (Sonic Solutions makes good stuff). They didn't need to run away from the old name quite so fast. They could have waited until NAB in April 2004 (if that is where they are going to announce the next release) and wouldn't have lost a single sale.

This is nothing more than corporate ego getting in the way of progress. It is not a problem unique to Sony. A few years ago, Pacific Bell had its name changed to SBC after one of the countless telecom mergers. Exactly who did this benefit? Can you imagine how much shareholder wealth was consumed making new stationary, business cards, legal forms, etc., etc.? What's more, PacBell had enormous trademark goodwill that took almost a century to build up (including a brand new San Francisco baseball stadium). All this was just tossed on the junk heap (yup, PacBell Park will not be PacBell park for much longer). Stupid, stupid, stupid.

I get especially emotional, because I sold my first company, Ventura Software, to Xerox back in 1990, and watched them spend all their time and money on irrelevant corporate issues, and left the engineering group to dangle for almost eighteen months. Even though I was totally removed from it, I still hated to see five years of my company's work thrown down the drain. After they totally screwed it up and finally sold the remains to Corel, they got about ten cents on the dollar.

I think Sony will not be as grossly stupid, but I have not been encouraged by what has happened since last June. I had hoped my public comments here would get circulated at Sony and cause someone to take some action, but I don't think they have had any effect except to tick off SonyEPM. Too bad, because I have really been trying to help, even if it has meant being a little too blunt at times.

Send the zip to this link ftp://192.168.1.100/ it is a link to my hard drive that I will leave on for a day or so until I see the upload. Thanks a million for doing this. I'll put your zip file under a new section on my web page for V5 so that people can have the V5 and V4 versions!

Carson Calderwood

192.168.1.100 is a local IP address only accessible from your local network.

I have tried them and I am not having much luck. I am using vegas 4e, latest download. When I run the various scripts it seems to be calling for variables that it didn't before. DISCLAIMER - I am not a programmer. I usually understand enough to read through a script and tell what needs to be changed to make it have the correct variables for me. For example, when I run the AddMarkersAtInterval script it tells me that the marker variable has not been set. I don't see any where to set that. I did set the time variable. Another example is the createtracks script. When I run it, it gives me the following error: "variable timecode has not been declared." The variable is at 10000 which should be 10 seconds. Looks fine to me. If anybody that has the capabilities to evaluate this let me know. I will email you the zip with all the updated scripts. email me at cbcalderwood at yahoo dotcom.
thanks,
Carson

cheroxy, after you change the import statement it will no longer run in Vegas 4