Missed out on Nat's ideas for multiple timelines

rmack350 wrote on 3/16/2005, 9:27 AM

Nat,

Sorry to have missed out on the nested timeline thread. I'm going to try to restart this in a constructive manner...

The underlying desire is for powerful tools to manage projects and media, especially long form projects. I think that nested veg files addresses some of this. Also, since one isn't forced to nest a veg file, if one doesn't want to do so then one doesn't have to do so. A design requirement here should be that performance isn't affected if nothing is nested.

It seems to me that actual timeline nesting is a presentation issue. There's an underlying process going on and then there's the way that process is presented to users.

The underlying process would be that Vegas treat other vegas or acid compositions as if they were events. I suppose this would mean that vegas would take a database file (like the veg file) and "include" it in the current database. What you'd have then is a block of program info inside the main program info and that block would be treated as a unit.

This implies a lot of possibilities:
--First and foremost, a vegas project file that can manage multiple veg files. Not only could you open multiple instances of Vegas but now you could open multiple timelines in one instance of Vegas.
--Possibly a more robust model for grouping events since defining a set of events as a "Comp" or "subVeg" could be seen as a form of grouping
--Possible the ability to "lock" a comp because you can't change the contents or a comp or subVeg without actually opening it.
--possibility to merge a comp or subveg back into the main veg file
--possibility to background render those comps or subveg files. Because the contents of such a file are essentially locked, these are good candidates for background renders. The down might be that if you can prerender sets of events on the timeline you'll need to dedicate more space to hold those renders.
--possibility of allowing someone at another station to work on scenes (comps, subveg files) and then merge them back into the main project.
--Since you can define a set of events as a compositional unit, you can prerender those units. This could mean that people could have persistant prerenders because the prerewnder would actually apply to the events instead of the timeline coordinates. For instance, you can prerender transistions.

Probably the biggest issues would be storage space-more prerenders means more storage, and project settings mismatches. You need to make sure that everything on the scene/comp/subVeg is coming in at the sample level instead of the project setting level.

Rob Mack

Comments

BillyBoy wrote on 3/16/2005, 10:23 AM

As Vegas matures (6th version coming) the issue becomes preventing the application from becoming bloated to the extent so many features result in more sluggish performance. We already have unlimited timelines in Vegas. In my view adding support for more sub layers to existing timelines or whatever you want to call them is a step in the wrong direction which may result in making the application more sluggish and more difficult to master.

If the software team is looking for things to "fix", I humbly suggest addressing Vegas' biggest weakness; slow rendering times.

While adding on special effects, transitions and multiple timelines for sure slows down rendering, the fact remains freeware like VirtualDub greatly outperforms Vegas when comparing simpler rendering. A project that can take hours to render in Vegas takes mere minutes in VirtualDub. I know you can't compare apples to oranges, but when Vegas is stumbling along a 2 or 3 frames per second when VirtualDub can process the same file at 90-100 frames per second that's an area that should take priority over adding more bells and whistles that will likely result in even more sluggish rendering times. But that's just MY opinion. Others may differ.

ezway wrote on 3/16/2005, 11:03 AM

Hello,
Here's my 2.2 cents. In C++ we have pco's, pre-compiled objects, this means they are NOT compiled into the final exe file, but rather they have been reduced to a binary form, and stored. This cuts the compile time down considerably.

Transfering these thoughts to Vegas we might show a track as complete via user action (check menu), and using HIPPO (which is a multi-threaded assembler that renders in the background) create an object for this finished track.

As you continue with the project more and more tracks are checked off as complete by the user, and more and more tracks are precompiled and saved ready for render.

One problem is that filters must be applied to the track object before pre-render, as it would defeat the process to add a global correction after all pre-compiles are complete.

This will cut the final render down by at least 60%.

I am sure Sony engineers are busy working on this, but these are my thoughts at this time.

Also please remeber that the next generation O.S. (Longhorn and other 64 bit systems) will NOT use or support the use dll's, as the 3 GIG area of ram is reserved for true exe's and .net systems.

Now for those of you that have more than 3 GIGS or ram you will not be able to load dll's as the offset and entry points will not match a re- compile of dll's and more memory is not a workable solution.

I hope this helps,
Marty

rmack350 wrote on 3/16/2005, 11:31 AM

Well, obviously this thread isn't about looking for things to "fix" and render times are another issue, off the topic of project and media management.

But I think I can point out an area where you might be "on topic" here. I think we've heard some good things about background rendering in other apps, and how it can speed up a final render. If Vegas could treat events and sets of events as a unit then those parts are good candidates for background prerendering. And while background prerendering might chew up extra disk space, it should (if smartly implemented) speed up final render times.

What I'm suggesting is that the basic underlying structure gets you lots of good things, not just nested comps. If I nest an entire scene into Vegas and it prerenders in the background, I could have a big performance savings later on.

I used the word "include" just for you, BB. Think of the nested comp as a "server side include". Does this sort of data need to slow Vegas down? Not neccesarily, but I can see that if your comp has five tracks with complex FX then it should slow Vegas down just as much as if it was simply on the timeline. In this sense, the nested comp might be misleading because it would appear as one event but internally be more complex. That's where a background prerender becomes needed.

Look, we're close to NAB and I'm assuming we'll hear something about Vegas6 around then. Any talk about features or ideas isn't going to affect that.

Project and Media management is just one of several initiatives to be pursuing. Render time is another. They aren't mutually exclusive. And, yes, I think that there are project management issues that are more "core" than nested sequences, comps, scenes, whatever. It'd be great if the Vegas project actually knew which vidcap files applied to it. It'd be nice if the Vegas project knew what other priject files where associted with it. But nested comps ties in with this really well and some form of it is a natural progression of improved project management.

Some render time improvement might be made just by renaming "Best" to "Extensive". I suspect that people overuse "best" when "good" is perfectly fine.

Rob Mack

rmack350 wrote on 3/16/2005, 11:40 AM

Marty,

You're on the right track, I think. However, I think that people expect certain objects get prerenderd, rather than tracks. So, for instance, maybe you insert a page peel transition and then prerender. You want the peel to be rendered, not the track nor the timeline range (What Vegas currently does).

So, If vegas grouped the elements together as a unit then the peel could be prerendered and be persistent. This isn't much different from an actual nested composition. From there you extend the idea and export the group of events and their fx and transitions as an external object. Essentially a new veg file that could be work on elsewhere, or can be dropped into a timeline and treated as an event.

Rob Mack

BillyBoy wrote on 3/16/2005, 12:53 PM

I don't expect ANYTHING to get prerendered. Never.

My view... prerending is backward thinking. Rendering is suppose to be the last step. Not something you should be worrying about while still working on the project because all too often you'll prerender again and again, or be tempted to say the hell with it if you "prerendered" and in effect stiffle your creativity by not redoing something you might otherwise have done again.

But heck, those are just my opinions Rob, and obviously you're not interested in discussing different views in "your" thread which is the impression I got by you saying what you did. So this is my last comment to "your" thread since you made it rather plain you're only interested in comments that support your views. Got it.

Spot|DSE wrote on 3/16/2005, 2:43 PM

I kinda think the biggest challenge in all this particular course of conversation, is path-directing the pre-renders if you have nesting happening.
So, if you prerendered in "Comp A" and you then stack "Comp A" into "Comp C" while an editing partner is at work on "Comp B," when the "Comp B" project is dropped into the timeline, what then happens to prerenders related to "Comp A" and "Comp C." I'm sure it could be directed correctly, but 'feels' like it would slow down the session significantly were that the case. Why is it you feel that for example, the Peel needs to be prerendered as opposed to merely recompressed, allowing everything to stay in real-time with no background action?

However, as I'd said in the other thread, nesting would be very useful for composites, or team-editing. I love the way ACID manages these sorts of things, where you can drop an ACID project on the ACID timeline and have it be the complete song, in the middle of other songs or bits of songs, allowing easy remixes, compilations, etc.

rmack350 wrote on 3/16/2005, 3:36 PM

Hi Spot,

I was using peels as an example because they're simple. It could be anything. The point would be to select some events or a rangesand turn them into a comp. Presumably the comp could be made to start a background render, but it should be optional.

I see your point about how the prerenders might persist if you're working on the composition on one computer and then dropping it into a timeline on another. It's a bit more complex and the options could be:

1. use URI to track prerender location
2. use relative path
3. use absolute path
4. don't include prerenders

Actually, I wasn't really thinking of Comp A having a portable prerender at all, I was just imagining prerenders done on the comps when they're dropped into a timeline. I think you're talking about prerenders happening at the source. It's an interesting idea. Most likely you'd want your facility to run on something fast like GBe, and when you drop that comp on the timeline it might be that Vegas would need to go get the media and make it "local".

The more general question is how do you manage media files if you're working across a network? That is a much larger issue, and one that Vegas can address I suppose, but you're really looking at some sort of media server for the whole facility. So maybe it's best to back out to simpler setups. How would it work on just one machine?

The idea here is that the basic comp object contains the same sort of information as any veg file, so hypothetically, you ought to be able to include that timeline information into another timeline and treat it like an event. Without rendering it ought to just behave like a stack of tracks and events. If you decided to go ahead and prerender it, that prerender should just happen at idle times. It might just behave the same way that things get prerendered while you play a loop-the process just starts rendering staggered frames until it's done. If you go off for a smoke it out to render pretty fast.

This sort of prerender isn't the sort of thing you should sit around waiting for. You need to be able to work, it needs to get out of the way.

From a feature design point of view I can see a need to really define the user's expectations of what they can do here. The problem of moving media around a network is important, but probably can be dealt with separately

Rob

filmy wrote on 3/16/2005, 3:49 PM

>>>nesting would be very useful for composites, or team-editing. <<<

YES!!!

I mention this a lot but I look at a bulk of Vegas users as DIY-ers. However to take a step further into the relm of "team effort" and, IMO, what many "pro" projects really are - team efforts. So you have to consider adding things like this to something that might strive to be something more than what it is percived as.

For example creating an opening title sequence is an artform unto itself. So nesting would come in very handy if you could get a "nested" version to work on, or put into the rest of the edit. You wouldn't have to worry about all the sync issues every time that part changed....and having it as part of the overall project would be better than just having a slug there until 6 months or so down the road when it was finalized.

As for pre-renders - i sometimes do this. For a current project I cut an opening sequence and pre-rendered it several times. I did this in its own project and imported the pre-render into the rough cut edit. Part of the reason was the final verison of the opening would be sepi-toned and I wanted them to get a rough idea. Plus it would change many times and I did *not* want it to be at the head of a feaure with so many changes being made. It was easiest for me to do the prerender, and because there is no nesting, having the "original" reside in its own project. The final verison was "locked" and brought over to the final locked edit. (And FYI the opening title sequence was done across the country, in After Effects. They rendered it out uncompressed, burned it and mailed it to me. I imported it into the project. There were 4 versions of that done as well.)

Spot|DSE wrote on 3/16/2005, 4:41 PM

Rob, one of the things we do here on larger projects, is store everything on one of two 1.5TB RAIDS that are on the network. On a giganet, (with DV) the files act as though they are local, and various people can work with the files. OR, projects are stored on 1394 drives that carry a veg file with the project files. This is very handy, because I can ship something off for instance, to Jeffrey Fisher in Chicago, where he'll build a sequence, and then eventually send me only the veg because I have the original media here, and only need to search/specify the drive. We've had one instance where a trainer in DC sent the original media, and I could follow along with his edits as he sent me .veg files as we completed the project. Usually, we're working chapters/packages/segments/teasers, and pieces, so we'll have more than one guy working on it. We'll render out a piece, drop it in the "master" timeline. But if there are changes, it has to be rendered again. That all takes time, sometimes too much time.
In FCP or Premiere, we can use a sequence as a placeholder, kinda like empty events in Vegas, but we can see what is happening. Once someone saves a piece of work in FCP, the master sequence is updated regardless of where I am in the flow. Great way to either team work, or if you're a "DIY" as Filmy puts it, you could build titles, teasers, interstitials, and programme media all separate, and update a master project at once.
In a way...we already have nesting in the form of compositing, one parent can control many children while still owning its own behavior. ACID kinda works this way, drop an acd file on the timeline, it adopts the characteristics of the master file and can be remixed, or used as part of a compilation. At NAB, we'll have a guy doing a whole session on ACID and sharing compositions/project comps.

Nat wrote on 3/16/2005, 5:10 PM

Hey Rob,
Thanks for bringing back that thread. I was really asking for people's opinions/ideas and did not expect it would yet start another (unrelated) fight.

Thanks for the comments guys !

Nat

Nat wrote on 3/16/2005, 5:12 PM

While we're on the subject. Could someone explain me how the "include project" feature works in Acid ? Looks very nice.

Nat

ezway wrote on 3/16/2005, 5:26 PM

Billy Boy,
Yes, but if like Rob says certain objects could be pre-rendered, and using multi-threadin background processing would certainly save a ton of time.
A twenty minute short took 14:00 hours and change to render, this is on a twin 2.6 ghz intel xeon system. I shutter to think of a feature length flim on a 1000 mhz system, one might take a vacation, raise a child, or some sort of lenghty process my brain can't think of for comparison purposes, but multi-threaded (just in time) rendering is the way to go, thing is we must have a wizard in addition to what we have now, so we can make these choices.
The Wizard might ask for you to apply all filters to one track first, then a render time it would exclude all the filter(s) not used.
Another assumption might be to "know" what resourcess are available to Vegas, (if networked may Vegas use computer #31 from midnight to dawn).
I understand this is partially used in Vegas 5 but when I worked on SETI we would use broadband connections around the world for compiling.
I think about the very nice lady at our old office who did word processing on an extreme machine, and all the ticks that went to waste.
Best Wishes,
Marty

Erk wrote on 3/16/2005, 6:15 PM

DSE said -

"I love the way ACID manages these sorts of things, where you can drop an ACID project on the ACID timeline and have it be the complete song, in the middle of other songs or bits of songs, allowing easy remixes, compilations, etc. "

I really like the sound of that! (pun intended). I would love to be able to drop veg files on a timeline in the same manner.

Nat wrote on 3/16/2005, 6:18 PM

I downloaded the Acid demo and I'm trying to understand how to drop a project on the timeline, anyone can help ?
Thanks,

Nat

rmack350 wrote on 3/16/2005, 8:06 PM

All pretty interesting. I had suspected that GBe was enough to play media in a timeline but hadn't had an opportunity to try it. There are also media management solutions out there that look like they'll check out and lock media and other assets. That's probably overkill.

I keep media at home and at work. The great thing about Veg files is that they're very easy to email or to pop onto a thumb drive. Given this, it'd be easy to send someone a disk of media and they could just email you the veg file to pop into your project. (Or, of course you could open up the veg file they sent you and just render it before poping it into your master project).

I tend to use photoshop files in a similar way. You can drop the photoshop image onto the timeline and then every time you edit the layers of the file, the changes show up in Vegas as well. It's pretty flexible, even though Vegas can't actually manipulate the layers.

But getting back to nesting Veg files, you probably wouldn't have to render the nested bits ('tho you might want to). Whether you render or not, being able to package up a bunch of timeline elements into a comp essentially lets you lock them all together. Locking is also attractive.

Rob Mack

Nat wrote on 3/16/2005, 8:22 PM

Regarding editing graphics, I do the same thing with Fireworks and I love it. I've got fireworks open on the right monitor and the changes I make are updated in realtime in Vegas. I also do this with a friend on the network and it works very well, he'll edit the graphics while I edit the video.