Arbitrary Parameter Data

[Christian Lett]

Hi,

A quick question about adding multiple arbitrary parameters.

Do you create a single struct/class containing all your data for ALL your arb params, or do you have a struct/class per arb param?

e.g.

// Single struct with data for two arbitrary parameters

struct AllMyArbsData {

    A_long  arb_1_fooL;

    PF_FpLong arb_1_barF;

    A_char arb_2_textC[128];

}

// or... Two structs with data for each arb param separately

struct Arb1Data {

    A_long  arb_1_fooL;

    PF_FpLong arb_1_barF;

}

struct Arb2Data {

    A_char arb_2_textC[128];

}

It's unclear from the example projects how to handle multiple arb params. The callbacks for setting dephault, print, etc. don't check for a given parameter ID. Of course in the examples there is only the one arb parameter... I'm not at my dev computer at the moment so can't check, but, for example CreateDefaultArb doesn't have an extra parameter, so there's no way of checking which arb is being referenced.

Thanks, C

[shachar carmi]

the arb param needs it's default data, and needs to be handled. if you need

different initialization or different handling you'll need to implement

different functions for each arb param.

there are a couple of ways to go about it.

1. C style.

when a param is defined, you can place a new "default data creator"

function for each arb.

when AE calls for PF_Cmd_ARBITRARY_CALLBACK, one of the data bits it

transfers tells you the disk_id of the called param, so you can use a

switch to call the right handling function for the specific arb.

2. C++ style.

the last param on the arb definition is a pointer which will be sent back

along with every call for PF_Cmd_ARBITRARY_CALLBACK.

put a pointer to some arb handing class in there, with virtual handling

methods. this way you can create a general arb handling class and just

override the methods you need for each specific arb.

i personally opted for the C++ option, and it made dealing with arbs one

hell of a lot easier.

[Christian Lett]

Thanks Shachar.

I was wondering whether arbs are the way to go at all, actually; one of my custom UI params is just a graphical front-end for a choice selection, so I guess I can just override the events for a Popup, since each choice corresponds to a popup choice anyway.

The other UIs are currently handling multiple other sliders that are grouped under hidden topics (and never unhidden). Since none of the custom UI parameters can be keyframed, perhaps arbitrary data handling is complicating things somewhat!

[Christian Lett]

Hi again Shachar.

I'd love a bit of clarification, if you'd be so kind!

For the C++ example, are you suggesting creating a class (class ArbHandler) that has, as virtual methods, each of the arbitrary callbacks, e.g. PF_Arbitrary_NEW_FUNC, etc.?

Some of these, such as PF_Arbitrary_DISPOSE_FUNC, would never need to be overridden, since they deal only with extra->u.dispose_func_params.arbH, whereas PF_Arbitrary_NEW_FUNC, would have to be a pure virtual function and would always be overridden, right?

(As the SDK is 95% C, I've gotten into the habit of doing everything in C, then regretting it later, and refactoring into C++, so my C++ knowledge isn't as good as it should be!).

A couple more questions:

1) Would a specific arb inherit class ArbHandler, e.g. you'd have a new class called MyArb : public ArbHandler, which had all the arbitrary data as its attributes (essentially the contents of the struct CG_ArbData used in the example in ColorGrid)?

2) Where do you declare the object MyArb, that you add as the refcon in Param Setup? This is the bit I'm most confused about... I think!

Thanks, Christian

[shachar carmi · Accepted solution]

yes, some of the handler's functions could be the same for all arb types. i

personally found that except for the "create new" function, i hardly ever

change anything between the handlers of different arbs.

as for storing the arb value in the arb handler class. you can do that, but

why? either you create the data and send it over to AE to store, or you get

data from AE to process and return. why would you want to store the data in

the handler?

that also has to do with your next question. (we'll swing back to the

previous soon)

where do i create and store the handlers? i do that during global setup,

and store them in the global data structure. then during param setup, i

pass the pointer to these handlers.

if you do so, you'll need to create a handle for these classes, initialize

them using "placed new", and keep the handler locked throughout the

session, so the handles don't move.

back to the previous question. if you allocate a handler that can serve a

few arbs, then storing the value in the handler class would not allow you

to use the same allocated handler for all.

if the handler is "neutral", then you could reuse. i found that sticking

with the generalized arb handler and re-using it saved me a lot of time.

[Christian Lett]

Thanks again Shachar. That all seems to be working great. It took me a little while to figure it out, but it all makes sense now.

Only problem is that my AE crashes now when I save the project. When I step through the flatten handler it works OK so it must be happening somewhere else. Frustrating as the debugger doesn't give any kind of hint as to where the problem occurs (just jumps into assembler).

Another thing - despite my project only having one instance of my plugin, it seems to call Copy and Flatten dozens of times, which seems odd. What on Earth it's doing is anybody's guess!

[shachar carmi]

is it possible that you're writing a bigger size of data chunk than you

allocated for the flat data? that might corrupt pieces of ram that don't

belong to you and can cause AE to crash when accessing these bits.

On Fri, Jun 3, 2016 at 10:57 PM, Christian Lett <forums_noreply@adobe.com>

[Christian Lett]

The crashing seems to occur during disposal of the arb (PF_Arbitrary_DISPOSE_FUNC).

Because the generic Arb Handler class has no idea of the data structure used to store the arb data (this is only passed to the virtual New Arb function I overload in the subclass), I have a protected data_size attribute, that's populated during NewArb. I just tried setting this to x10 but it still crashed.

I must be doing something fundamentally wrong somewhere...

[shachar carmi]

no choice but to strip the plug-in down until you're left with a couple of

wires and a crash.

[Christian Lett]

It was down to the disposal of the arb, in the PF_Arbitrary_DISPOSE_FUNC call.

I've since disabled the handle disposal in this call (so now the call does nothing), and everything works perfectly. There doesn't seem to be any issue with not disposing of the handle - maybe Zac or someone could weigh in here. It only seemed to be a problem when the project was saved - the call to dispose was made, and then the app crashed.

Cheers for your help Shachar - my C++ arb param handler has made my life nice and easy!

C