Skip to main content
benp1711322
benp1711322
Inspiring
February 5, 2020
Answered

Arbitrary param/handler is hyperactive? [SDK]

  • February 5, 2020
  • 1 reply
  • 1751 views

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. 

 

 

 

Correct answer benp1711322

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


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! 

1 reply

benp1711322
benp1711322Author
Inspiring
February 5, 2020

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. 

S
Community Expert
shachar carmiCommunity Expert
Community Expert
February 6, 2020

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

benp1711322
benp1711322Author
Inspiring
February 6, 2020

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'. 

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices