regenerating only when something changes...

[Steve Gase]

I watched the xl4.0 demo and saw that save/channel regeneration and the impact on cpu load as the work was handed out over the multiple procs... nice.

what if... 

what if for each model and each time period there as a dirty bit that was used to indicate if the regeneration is even needed?  if you drop in an effect, then that model and that time period is marked as needing to be regenerated.  changing a time would mark all models before and after that time event as dirty.

[Gilrock]

Yeah we've been discussing several options.  Right now when you hit Save it's not only just regenerating the NC effects it's merging all the data layers that may exist above and below the NC layer.  Right now if you move or delete effects it can trash the data layers beneath.  We've provided a way to restore it by hitting Render All.  We've talked about trying to keep that up to date on the fly and then a Save might be almost immediate.  We would need to be able to narrow down the update to a slice.  I think Dan does that already for the NC layer but the data layers aren't accounted for and that's why the Save currently needs to re-render everything.

[sean]

yeah steve, we have been talking about a dirty bit on models. we also were saying instead of just a bit, how about a starting and ending frame. they start with start frame =0, end frame = last frame. if you do a save both start and end get set to -1.

If you edit just one effect in the middle of the sequence we block the range out, start frame =100, end frame=200 if you touched anything from 1-2 seconds with 20fps.

now we need to render only 1000 frames instead of the normal 3900 frames for a song.

i expect when this sort of logic gets implemented you will see saves tha are only a few seconds instead of the current 40 seconds.

[arw01]

Sean, where do these discussions occur, are they phone calls between developers or email chains?  Just lurking on those conversations would certainly aid a few of us get our heads about the code a lot more, and occasionally a lurker smarter than I can see the forest better.

[sean]

Almost all are email threads. Matt brown, capt Murdoch, Gil jones, don julien, Dan kulp, Dave Pitts and myself.. Sometimes a subset gets on the phone