Premiere doesn't call PF_Cmd_SEQUENCE_FLATTEN when hitting CMD+S

[reimundd1593001]

Hi,

In Premiere Pro it seems that PF_Cmd_SEQUENCE_FLATTEN isn't immediately called when hitting CMD+S / Ctrl+S after our plugin has returned PF_Cmd_DO_DIALOG so user settings get lost. All the changes applied during PF_Cmd_DO_DIALOG are honoured and the frame has been rendered properly. However, it takes Premiere about 5 seconds or so, before it calls PF_Cmd_SEQUENCE_FLATTEN when the session is saved.

The issue happens both on Windows and Mac OS.

Is there any way to "force" PF_Cmd_SEQUENCE_FLATTEN (we already set PF_OutFlag_FORCE_RERENDER in the out_data's out_flags) ?

Thanks,

Reimund

[BarlaeDC]

Moving to Premiere Pro SDK forum.

Malcolm

[Bruce Bullis]

Why does your plug-in care, when PPro flattens sequence data?

[reimundd1593001]

The point is that PPro doesn't flatten the sequence data at all right after DoDialog, so it doesn't save the correct state, in case the state has changed during DoDialog. It seems we have to wait about 4-5 seconds after our plugin has returned from DoDialog before saving the session or PPro won't call into SequenceFlatten at all.

[Bruce Bullis]

The fact that PPro doesn't flatten the data immediately, does not imply that PPro isn't saving the updated sequence data.

If your DoDialog changes sequence data, great; that change is saved, in your non-flat sequence data.

If you manually save the project within that 5 seconds, is the sequence data flattened?

[reimundd1593001]

Hi Bruce,

Thanks for your quick respons.

It does not flatten the sequence data (at all) if I manually save the session within the mentioned time interval. And I think that is the poin, PPro thus doesn't restore the plugin state once the saved project is restore.

Working with the unflat data after DoDialog isn't the issue it does that just swiftly. It's only that my plugin state isn't restored correctly if the project ist saved to quickly after DoDialog and I think that is because it doesn't acknowledge the changes made during DoDialog in terms of flat sequence data saved to disc under the above conditions. This happens on both Mac and Windows btw.

[Bruce Bullis]

It's only that my plugin state isn't restored correctly if the project ist saved to quickly after DoDialog and I think that is because it doesn't acknowledge the changes made during DoDialog in terms of flat sequence data saved to disc under the above conditions.

I'm curious about the phrase, "...I think that is because..."

Flatness / unflatness aside, are you seeing a disparity between "most recent settings, as specified by user in your dialog" and "plugin settings being read (restored) from disk"?

If so...how are you testing that?

Aside: Reimund, I believe you may have actually found a problem; I just don't precisely understand the problem, as described. If sequence flattening were as fundamentally broken as your initial problem report suggests, we'd have plug-in developers at the Adobe offices with torches and pitchforks.

I remain hopeful we can figure this one out.

[reimundd1593001]

Hi Bruce,

Here's what I'm doing:

1.) Create a new project, add a clip

2.) Instanciate the plugin under consideration

3.) Open the plugin's Dialog, apply some changes

4.) Close Dialog (settings are correctly applied by PPro)

5.) Save project

6.) Close and restore project

Now for some reason, the sequence data and thus plugin state restored in 6.) do not correspond to the state/settings that should have been saved after 5.) unless I wait a couple of seconds after finishing step 4.) and before saving my project. The only difference I can see in the debugger is that in case a.) SequenceFlatten is performed if I wait long enough before saving or b.) it is not.

Hehe, "torches and pitchforks", while I think this image is hilarious that's certainly not what I'm trying to imply.

[Bruce Bullis]

Can you send me (directly; b b b at adobe dot com) your declarations for flat and non-flat sequence data structures?

Can you repro the the behavior using any of our sample plug-ins?

I didn't mean you were brandishing torches or pitchforks; I meant that, if our sequence data handling were as fundamentally broken as your problem report initially suggests, the community would be up in arms.

[reimundd1593001]

Thanks for your assistance, Bruce! And no, I wasn't trying to imply that PPro's flattening/unflattening sequences were "that" broken, either. We never had any problems with them before, it's only that things get broken under the mentioned conditions, but the actual cause for the described behavior may well be on our end.

I haven't yet had the chance to try reproducing it with the SDK examples (just signing off into a 2 week summer holiday), but I'll provide the info as soon as I can.

Regarding my flat sequence data structure (trying to tell from the top of my head now), it looks pretty much like this:

typedef struct

{

    uint32_t magic; // 'aex1'

    uint32_t totalSize; // Size of the sequence data /wo header

    uint64_t token; // Random 64bit id generated upon first instanciation

    char bytes[1]; // Opaque data chunk holding plugin state (variable size = totalSize bytes)

} aex_flat_sequence_data;

The token is used for instance identification purposes during the flattening/unflattening process and is converted into a pointer to a certain plugin implementation instance at runtime using a std::map.

Let me know if there is anything else you need.

[Bruce Bullis]

    char bytes[1]; // Opaque data chunk holding plugin state (variable size = totalSize bytes)

Sizes of flat data structures can't vary.

[reimundd1593001]

Please don't misunderstand the term variable size in that context: For a given plugin the byte size is a constant that corresponds to the size allocated for the sequence data handle (+header size). What I mean by variable here is that different plugin implementations will obviously have differently sized state chunks.

[Bruce Bullis]

You use the same sequence data definition, across multiple plug-in implementations? That sounds challenging; what's your motivation?

If 'bytes' is in a flat data structure, it will always be a (very small) array of chars.

If the opaque data chunk which holds the plug-in state is larger that two chars, then what you've defined [above] is not a flat data structure; it's still referring to external bits.

[reimundd1593001]

I'm perfectly aware of what you're saying. To be perfectly precise it works as follow:

typedef struct

{

    uint32_t magic; // 'aex1'

    uint32_t totalSize; // Size of the sequence data /wo header

    uint64_t token; // Random 64bit id generated upon first instanciation

} aex_flat_sequence_data_header;

typedef struct

{

    aex_flat_sequence_data_header header;

    char bytes[1];

} aex_flat_sequence_data;

The sequence data handle is allocated with sizeof(aex_flat_sequence_data_header) + sizeof(some_specific_plugin_opaque_chunk_size)

aex_flat_sequence_data is then used for a cast to access the opaque data chunk bytes, easily.

The motivation for this kind of approach is that our plugins expose a generi, vendor specific API that is wrapped into various plugin formats including premiere/after effects using appropriate Wrapper implementations.

[Bruce Bullis]

The sequence data handle is allocated with sizeof(aex_flat_sequence_data_header) + sizeof(some_specific_plugin_opaque_chunk_size)

Okay, that sounds much more sane, thanks!

Can you repro the sequence data updating failure, with a PPro SDK sample plugin?

[reimundd1593001 · Accepted solution]

I'll try to reproduce with the SDK examples and let you know the results asap.

[reimundd1593001]

Hi Bruce,

here's an update: It looks like we managed to fix this one by removing the PF_OutFlag2_PPRO_DO_NOT_CLONE_SEQUENCE_DATA_FOR_RENDER flag from the PiPL and GlobalSetup() while taking respective measures to make our wrapper's render callback thread safe. While the latter isn't a bad thing at all I'm still puzzled why this should be required at all or why the flag should make a difference regarding the described bug.

The SDK examples aren't helpful here either because as far as I can tell there isn't any plugin that implements both the sequence data protocol as well as a DO_DIALOG callback while setting the mentioned flag at the same time, but I'm sure something basic can be hacked together quickly for further investigation.

Best,

Reimund

[Bruce Bullis]

Glad you figured it out.

Unsubstantiated theory: The same logic that makes us not clone the sequence data, makes us decide that we don't need to flatten the sequence.