Standard version: 2.0
Major Change
entered by Pierre Jasmin, revisionfx.com
I was under the impression that paramEditBegin would be interpreted by host not just in terms of grouping parameters for undo but as well as indicator that we are about to write a bunch of key-frames. So tested in Nuke, Fusion and Natron and same, even within EditBegin-End each time we add a key-frame within InstanceChanged which is what happens during a sequence analysis, InstanceChanged is called - so instanceChanged is called recursively and if you have 3 values to write for 3000 frames, well Instance Changed is called 9001 times which makes this not very interaction friendly.
paramEditBegin: If a plugin calls paramSetValue/paramSetValueAtTime on one or more parameters, either from custom GUI interaction or some analysis of imagery etc.. this is used to indicate the start of a set of a parameter changes that should be considered part of a single undo/redo block.
Option 1: Modify paramEditBegin definition so no extra InstanceChanged is called until the paramEditEnd is called
Option 2: Add paramEditBeginWrite in a Parameter Suite V2
Honestly I have no idea what is host friendly here for case where as part of same "block", one writes a stream of data, then wants to read it to write a second one. Right now this works in 4 tested hosts like that. It would be nice that it works even if it forces the host to block main UI thread interaction while a plugin is in InstanceChanged and has not returned from paramEditBegin.
For reference in AE API we can do:
suites.KeyframeSuite()->AEGP_StartAddKeyframes
for(i=Startframe; i<=Stopframe;i++) {
...
suites.KeyframeSuite()->AEGP_AddKeyframes
...
}
Option 3: Could be also a dynamic property added as another string to param prop CacheInvalidate to tell host to suspend tracking changes until we are out of Instance Changes for this parameter.