• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

How do people manage versioning their PiPLs?

Explorer ,
May 23, 2019 May 23, 2019

Copy link to clipboard

Copied

I asked this in the general forum initially but this is a more appropriate place. It's mind boggling how difficult it is to find the forums for these software packages to the casual participant.

I have a pair of plugins that I maintain for an enterprise application. These plugins are released alongside the external applications for which they're developed. A new version of the plugins is released every six months or so, and many users have several versions of the plugins installed at the same time so that they can just pick and choose based on the version of the other apps they're targeting.

This was all well and good, until After Effects CC 2019. Now, only the first plugin alphabetically gets loaded. The others are completely ignored as far as I can tell; the EntryPointFunc isn't called. The contents of the PiPL file aren't terribly well documented (at least, not in the AE SDK Guide PDF), it just sort of vaguely says "there's stuff in there but don't worry about it just use one from the sample code." It even goes so far as to wrap the section up with "Why do I need to know all of this? You don't..."

So basically my users are screwed. Going forward I guess I can try to implement something in here which does stuff to do things but... What do I do? What does the "Version" mean? How should I update these files so that multiple installations of the same plugin works? The plugin installers already tag the installation plugin names with the version, e.g. MyPlugin-1.0.aex, MyPlugin-1.1.aex, etc. (It doesn't really matter but they're actually symbolically linked into the Plug-ins folder from elsewhere.)

My preference would be for Adobe to revert this "new intelligence which skips loading plugins that might already be loaded" check since it cannot actually be accurate ever (since it's based on alphabetic order). My next preference would be for this file to be documented or have a reference to where to find that documentation in the PiPL section of the AE SDK Guide.

Here's my PiPL, for all of the plugins:

#include "AEConfig.h" 

 

resource 'PiPL' (16000) { 

    {    /* array properties: 7 elements */ 

        /* [1] */ 

        Kind { 

            AEGP 

        }, 

        /* [2] */ 

        Name { 

            "MercuryAEExport" 

        }, 

        /* [3] */ 

        Category { 

            "General Plugin" 

        }, 

        /* [4] */ 

        Version { 

            196609 

        }, 

        /* [5] */ 

         

#ifdef AE_OS_WIN 

#ifdef AE_PROC_INTELx64 

        CodeWin64X86 {"EntryPointFunc"}, 

#else 

        CodeWin32X86 {"EntryPointFunc"}, 

#endif 

#endif 

    } 

}; 

TOPICS
SDK

Views

626

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
May 23, 2019 May 23, 2019

Copy link to clipboard

Copied

i don't fully understand what you mean when you say your users have

multiple versions of the plug-in installed.

how do the different versions differ? does their aex file have a different

name? does the internal name in the PiPL differ? or are they all the same

but located in different folders?

you said the first alphabetically is loaded but i don't know in what sense.

On Fri, May 24, 2019 at 3:52 AM mightysprite <forums_noreply@adobe.com>

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
May 29, 2019 May 29, 2019

Copy link to clipboard

Copied

LATEST

https://forums.adobe.com/people/shachar+carmi  wrote

i don't fully understand what you mean when you say your users have

multiple versions of the plug-in installed.

how do the different versions differ? does their aex file have a different

name? does the internal name in the PiPL differ? or are they all the same

but located in different folders?

you said the first alphabetically is loaded but i don't know in what sense.

The plugins folder contains MyPlugin-v1_0.aex, MyPlugin-v1_1.aex, MyPlugin-v2_0.aex, MyPlugin-v2_1.aex, etc. (Filenames differ but this is the setup.)

PiPLs are the same, as the documentation says "don't worry about what's in it and do not attempt to change it."

"First alphabetically" means that in the above list, "MyPlugin-v1_0.aex" loads first; I maybe wasn't explicit that the filenames are what are treated as "alphabetical" in this context.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
May 24, 2019 May 24, 2019

Copy link to clipboard

Copied

If you want to have different versions of a plugin to be active in parallel within one AE session, you need to give them unique "AE_Effect_Match_Name" fields in the PiPL.

Furthermore, the version number you report in PF_Cmd_GLOBAL_SETUP by filling the field out_data->my_version needs to match the "AE_Effect_Version" field in the PiPL exactly. There is a convenience macro PF_VERSION and some more information provided in the AE_Effect.h header file:

/** -------------------- Version Information ----------------------------------

**

** Please use these macros for designating the version information

** of your plug-ins. Should After Effects encounter more than one version

** of a specific plug-in when it starts up, it will use this information

** to decide which plug-in to honor. The plug-in version information

** (field 'my_version' in the PF_OutData) should be set at GLOBAL_SETUP

** time.

**

** This version information is meant for your version control, and should

** not be confused with the min_version and desired_version fields in the

** PF_OutData structure, which refer to the version of the PF specification.

**

**/

#define PF_Vers_BUILD_BITS        0x1ffL

#define PF_Vers_BUILD_SHIFT        0

#define PF_Vers_STAGE_BITS        0x3L

#define PF_Vers_STAGE_SHIFT        9

#define PF_Vers_BUGFIX_BITS        0xfL

#define PF_Vers_BUGFIX_SHIFT    11

#define PF_Vers_SUBVERS_BITS    0xfL

#define PF_Vers_SUBVERS_SHIFT    15

#define PF_Vers_VERS_BITS        0x7L    // incomplete without high bits, below

#define PF_Vers_VERS_SHIFT        19

// skipping these bits for similarity to Up_Vers_ARCH_*, currently unused in PF

#define PF_Vers_VERS_HIGH_BITS        0xfL    // expand version max from 7 to 127

#define PF_Vers_VERS_HIGH_SHIFT        26

// b/c we are stripping the stand alone vers value for two fields

#define PF_Vers_VERS_LOW_SHIFT  3

#define PF_Vers_VERS_HIGH(vers) ((vers)>>PF_Vers_VERS_LOW_SHIFT)

#define PF_VERSION(vers, subvers, bugvers, stage, build)    \

    (A_u_long)(    \

         ((((A_u_long)PF_Vers_VERS_HIGH(vers)) & PF_Vers_VERS_HIGH_BITS) << PF_Vers_VERS_HIGH_SHIFT) |   \

        ((((A_u_long)(vers)) & PF_Vers_VERS_BITS) << PF_Vers_VERS_SHIFT) |    \

        ((((A_u_long)(subvers)) & PF_Vers_SUBVERS_BITS)<<PF_Vers_SUBVERS_SHIFT) |\

        ((((A_u_long)(bugvers)) & PF_Vers_BUGFIX_BITS) << PF_Vers_BUGFIX_SHIFT) |\

        ((((A_u_long)(stage)) & PF_Vers_STAGE_BITS) << PF_Vers_STAGE_SHIFT) |    \

        ((((A_u_long)(build)) & PF_Vers_BUILD_BITS) << PF_Vers_BUILD_SHIFT)    \

    )

#define PF_Version_VERS(vers)        \

     (((((A_u_long) vers) >> PF_Vers_VERS_SHIFT) & PF_Vers_VERS_BITS) + (((vers >> PF_Vers_VERS_HIGH_SHIFT) & PF_Vers_VERS_HIGH_BITS) << PF_Vers_VERS_LOW_SHIFT))

#define PF_Version_SUBVERS(vers)    \

    ((((A_u_long) vers) >> PF_Vers_SUBVERS_SHIFT) & PF_Vers_SUBVERS_BITS)

#define PF_Version_BUGFIX(vers)    \

    ((((A_u_long) vers) >> PF_Vers_BUGFIX_SHIFT) & PF_Vers_BUGFIX_BITS)

#define PF_Version_STAGE(vers)    \

    ((((A_u_long) vers) >> PF_Vers_STAGE_SHIFT) & PF_Vers_STAGE_BITS)

#define PF_Version_BUILD(vers)    \

    ((((A_u_long) vers) >> PF_Vers_BUILD_SHIFT) & PF_Vers_BUILD_BITS)

enum {

    PF_Stage_DEVELOP,

    PF_Stage_ALPHA,

    PF_Stage_BETA,

    PF_Stage_RELEASE

};

typedef A_long PF_Stage;

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
May 29, 2019 May 29, 2019

Copy link to clipboard

Copied

Thanks Toby, this gives me a few things to chew on.

This is just a "general" plugin, so there's no effect going on here. It's basically a plugin that communicates with external resources about the state of the scene. It is annoying that it is versioned along with the software that it communicates with, and I've been working to alleviate that challenge as I've had the opportunity to move the specific-to-the-external-software modules into external applications with which this plugin communicates but legacy setups have a way of calcifying.

All of that PF_Vers stuff does point to how to specify the version, so thanks for that. It would be nice if the docs regarding the PiPL went over some of the fields that were important and how they should be laid out. I even understand why Adobe would make the change to prevent old plugins from loading when newer ones were available but it is going to cause me some pain as I need to hotfix a lot of software if it's going to be compatible with CC2019.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines