How to set GeneratorSettings metadata?

Hi all,
I need to store some metadata for my plugin in a document and while I started off with using XMP for this, this is giving me all kinds of technical headaches so I would like to try an alternative approach. I understood that generatorSettings (on Doc/Layer level) can also be used for plugin specific metadata. While getting this data is easy as pie, I have not a single clue on how to set/add my data (just a string) to this. Can someone help me out here with a quick BP example or point me to one? It would be very much appreciated :slight_smile:

I think I figured it out already… pretty straightforward :slight_smile:

        {
            "_obj":"set",
            "_target":[
                { "_property":"generatorSettings" },
                { "_ref": "document", "_id": 101 }
            ],
            "to":{
                "_obj":"generatorSettings",
                "myCustomProp":"MyData"
            }
        }

Unfortunately, this also suffers from the same “problem” (for my use case at least) as I noticed with XMP in that changes to this are not reverted on Undo even if a history state is created :frowning:

Not sure if there’s an issue with the latest API to set/retrieve XMP, with respect to file state, I’ve also not tried out setting layer XMP (like you reported in an earlier post). But for what it’s worth, in our pipeline we’ve been using XMP for ages to attach metadata to documents. We moved to UXP a year ago at a point in time when XMP still had to be retrieved and set via batchPlay, but I can confirm that (at least doing it that way) completely follows file state and plays well with undo/redo. In fact we rely on that in our pipeline.

I would recommend giving XMP another try with a minimal example and post your code here so to better help you.

You should probably check out these posts: Document XMP metadata

And this more recent one:

Thanks @dotproduct yes I do believe now that sticking with XMP is the better option. Thanks for your take and link.

But then XMP only at Document level. XMP data at Layer level for sure is not correctly history-tracked from what I’ve seen, or I’m missing some non obvious step to handle this. I’ll try posting a minimal example later, but honestly I’m doing nothing special (but then again that might be the issue?l

Yeah, I really can’t speak to XMP on the layer. It sounds like a bug worth reporting. In our pipeline we do associate metadata for particular layers by using their IDs, which stay constant over the lifecycle of a layer and across sessions. The only downside is that you have to track layer’s getting deleted or duplicated. But I’m not sure that layer XMP metadata gets duplicated when the layer is :thinking:

But I’m not sure that layer XMP metadata gets duplicated when the layer is

It does

Thanks for confirming. Also thanks for filing the bug for the layer XMP!

This wrong. You have to read and append existing data made by someone else as well. Otherwise your plugin won’t be compatible with mine. And customers have to choose one or another plug-in.

1 Like

Sure, sure, just a poc and all, not for production. Unfortunately, GeneratorSettings is not even usable for me due to changes to it cannot be undone with history stepping.

Ah the joys of cooperative shared data, with little more than crossed fingers that everyone will “play nice”.

Coming from years of InDesign development (where metadata is done right), it’s hard to fathom how lacking PS is in this department.

This batchplay is low level. It was used for generator plugins (RIP). Generator api had some wrappers around it. But not sure how much safer it was.

1 Like