An Open Letter to Sony Re: Full function scripting

2G wrote on 7/8/2004, 12:13 PM
Sony:

As a software developer with 27 years in the business, I fully understand the agonizing process of deciding what does and doesn't make the cut in a release of a product.

However, from my perspective, efficiency in post-production of my projects is critical to the success of my business. One of the biggest selling points of Vegas was the ability to write scripts to automate and speed up repetitive tasks.

Yet I am repeatedly hitting barriers due to an "80% API" that let's me do alot, but not all of these repetitive tasks. Not being able to control track motion via scripting has been severely limiting. I realize bezier masking is new in 5.0, but the scripting of bezier didn't "make the cut". I am continually getting "almost there" with a script, then having to abandon it due to a basic function in Vegas that isn't available in scripting.

For the next release (or even better a point release...) please consider prioritizing bringing the scripting function up to date with the functionality of the product.

If it's just too massive an effort to add all the omitted functionality in one release, I'm sure the forum community would be more than willing to help you prioritize. I'll start with my votes for 1) track motion and 2) bezier masking keyframes (using presets).

Again, I appreciate the function that is there, and I understand there's only so much runway. But consider the benefit you gain from having a robust scripting capability by having more and more value-add scripts available to enhance the function and appeal of Vegas. It's good now, and Vegas is already benefitting from Excalibur, etc., and all the scripts that are there. But I believe there would be much more scripting activity without the current missing functionality.

Thank you.

2G

Comments

dust wrote on 7/9/2004, 12:24 AM
Yes, I can back that up!

Though I'd like to mention that to me Vegas' scripting feature is _THE_ one feature that makes the real difference to all other NLE, including Avid et al! Of course I'm not sure how much it is a comemrcial advantage, as I don't know to how many people this feature is important enough to buy Vegas instead of Adobe/Ulead - only to "us" freaks, or also to a more mainstream public?

I definitely would appreciate a more complete API. Though I'm incredibly happy (in a figurative sense :-) that grouping is now functional - thanks again! This opens so many new possibilities, I'll first have to take full advantage of the new freedom (I already have many ideas in my mind). It is a bit symptomatic though that Vegas nearly "forgot" to tell us about the feature :-)

My wishlist for future API improvements (which are not that urgent anymore now, but of course nice to have ones); note that my personal focus is on workflow, not the effects themselves:

- Read access to status information the user set, like what ripple mode the user chose (after all it makes sense if a script obeys these settings as well). Maybe it is already available somewhere in the registry and Sony only needs to tell us what some of the registry registry entries mean? I already used this approach to save and restore layout settings.

- A possibility the user could set/reset "user defined flags" in the GUI that a script could read out. In the simplest case, this could be 5 or so LEDs that the GUI shows in a corner that can be toggled by clicking on them (or assigned to a key) - scripts could read them out and adjust their behaviour. This way scripts would not always have to pop up dialogs with checkboxes. In a more comfortable way, scripts themselves could "register" some GUI elements (like their own on/off-toggles) in a "script constructor" that's run the first time a script is run, or even when Vegas starts up.

- A comfortable possibility that scripts could store persistent information between Vegas sessions, so user settings within a script can be kept over to a later Vegas session. This can already be done by writing information into the registry (a technique I'm using), but a more comfortable way would be good.

- Set the visible portion of the timeline. Until now this needs to be simulated by setting the cursor and send a F3 and F9 keystroke using Wshell. Same about the vertical scroll position of the timeline (over tracks).

- Setting heights of tracks as shown in the timeline.

. A possibility to add tracks to a project that only serve as "memory deposits" and are only available to scripts, but not visible in the GUI or changed by GUI actions. Such hidden tracks should be saved with a project. Scripts could, for example, deposit proxied events in such tracks and access to them in a later session (this allows implementing nested tracks from scripts).

- A possibility to find out where the running (!) cursor was at script invokation. Until now, when you invoke a script while the cursor is "playing", Vegas.Cursor returns the position of the curssor as it was when playback started, not when the script was invoked (same as difference between Space/Enter/F12 when you stop playback).

- Make Vegas' actions available from within scripts.This might be impossible to do, but maybe it's possible to queue a list of such actions such that they are executed one after the other after the script terminates (or at least one such action). Until now you must put these actions to keystrokes and use WShell. -

- A more simple solution to the last point would be to make keyboard assignments available from within scripts.

- The possibility to configure the text appearing in a generated text event (until now it only shows "Sample Text"). I think there are other fixed featured of generated events that would be useful to be determined from scripts.

Thsi is only what comes to my mind currently. As I said, this is just a wishlist, not a criticism to Vegas. Adding the scripting feature itself was already a big step!
johnmeyer wrote on 7/9/2004, 10:00 AM
I would go one step further. The real issue is one of third-party support. The difference between software companies that succeed and those that eventually fade away is third-party support. Some may think that such support (meaning products that are meant to be integrated into the main product) follows a successful product; in reality, such support almost always creates the success.

The key is to create a fully-staffed, fully-funded, third party support group. This group develops SDK packages (Software Development Kits). They hold development seminars. They publish catalogs of all third party enhancements. The provide booth space at trade shows for partners. They provide a direct channel between developers and the engineering team developing the product.

Their success is measured by the number and quality of third-party products that support the company's flagship products. Want to know what I consider successful? Take a look at this page from Adobe's site:

Adobe Plug-Ins

Why doesn't a company with the resources of Sony, that has the quality software from Sonic Foundry, and the amazing breadth, depth and quality of Sony video hardware (which Adobe doesn't have) have an array of third-party products that exhibits this range and depth and quality??

It is an oversight by product management, one that should have been addressed long ago.

One of the major benefits of vigorously pursuing the third party community may not be obvious: It keeps Sony from creating a bloated product that does many things, but does none of them well.

Thus, I agree that the API should be more fully described, but in absence of fully-funded support of the third-party community, I don't think it will make much difference.
WL wrote on 8/8/2004, 8:23 PM
Do you know why the API is so important ... because it locks in your customers. $$$

It also has a life of its own, and over time, features/enhancements/addons grow richer and richer with minimal effort from Sony because the community (your customers and users) will be doing the work.

I think the scripting feature should also be extended to DVDA.