Arbitrary param/handler is hyperactive? [SDK]

[benp1711322]

I've made an arb param which has a simple struct of an A_long and a fixed length wchar_t[]. It's mostly set up and modified from the colorgrid sample. In both plugins the arbitrary handler function gets called many dozens of times, in the same sequence, starting off with lots of calls to PF_Arbitrary_DISPOSE_FUNC and PF_Arbitrary_COPY_FUNC (i.e. 22122122...),  followed by a much longer sequence of those two, then PF_Arbitrary_FLAT_SIZE_FUNC and PF_Arbitrary_FLATTEN_FUNC (i.e. 1234...1234...1234...etc). 

This very long cycling appears to be going on over Sequence Setup and update params functions, which ultimately seems to be messing with my somewhat complicated, but was fully working UI code.  Perhaps jamming AE up somehow. My arb has no UI of its own, it's inivisible and unsupervised with no ECW. 

Is there a way to get Arb parameters to behave more efficiently? Currently it just looks crazy -- in the Colorgrid sample, I count 3648 calls to PF_Cmd_ARBITRARY_CALLBACK just to load the plugin. 

[benp1711322]

I was mistaken above when I say that the over-active calls to PF_Cmd_ARBITRARY_CALLBACK prevent AE from executing other functions. This was in fact caused by a different problem. However, it would be good to know if this is normal/expected behaviour, or if there's a more efficient way to use an Arb to store data. 

[shachar carmi]

yeah, no. arb params trigger a ton of calls for copy, dispose and compare. that's just how it is.

[benp1711322]

Thanks Shachar. 

Can you tell me if I need to be concerned about the cascade of functions triggered by Arb getting in the way of other processes, including itself?  I'm having trouble getting changes to updated arb data to 'stick'. 

[shachar carmi]

i handle arb params only via AEGP_SetStreamValue(), so i don't have much intuition for the old fashioned way of using the param array passed to some calls...

if AEGP_SetStreamValue doesn't work for you as well, then yes, something is broken.

[benp1711322]

I've tried both. I've used the params[PARAMID]->u... + PF_ChangeFlag_CHANGED_VALUE way because it's easier to read the code. I've no idea what differences between that and get/setStream are, under the hood. 

The problem is that it any attempts to keep track of what's going on with debuging just produces a torrent of data. And breakpoints are equally useless. What it *looks* like *might* be happening is that Arb parameter code is running over itself, or in parallel. 

[shachar carmi]

can you post the code with which you set the arb data? perhaps it's a simple mistake there.

[benp1711322 · Accepted solution]

I've just found it. It was a slight error between Arb flatten/deflatten.

It's a large amount of complex, intereacting code to get right first time, and then which can fail non fatally without giving any clue as to where/why. 

I cured by writing really verbose debugs. 

It's taken nearly two weeks to get up and running, with some false starts. Not a job to take on lightly! 

[shachar carmi]

excellent! glad you got it solved!

[ThomasT]

Hi,

can you please point out, what your problem was. 
I got a similar problems. Lots of copy calls, but src are always new/default. When I changed arb params than they are disposed (and the ones I debugged it) and than it calls for new. 
Something I have done wrong but I couldn't figure it out.