Recreating AUParameterTree without destroying the tree object? Is it possible?

Question

Created Feb ’17

Replies 11

Boosts 0

Views 2.9k

Participants 6

I have a situation where at any one time my AudioUnit can be represented by only a few parameters or literally many 100s.

This dynamic situation is under the control of the user and the maximum number of parameters and their hierarchy cannot be predicted in advance. ( at least not accurately ).

When the parameters are to change I am setting the parameterTree property by creating a new tree with the child nodes and posting KVC notifications …

.. create childGroups …

[self willChangeValueForKey:@"parameterTree"];
self.parameterTree = [AUParameterTree createTreeWithChildren: childGroups ];
[self didChangeValueForKey:@"parameterTree"];

Most the of the app’s User Interface and AudioUnit is coded in Swift, the engine is in coded in C/C++ with an objectiveC AUAudioUnit class that acts as the go between hence the above.

However there is a popular host app that crashes when I do this and it looks like the host is hanging on to the parameterTree object that’s it’s passed originally when the AU first launches but never updates it even after the KVC notifications are posted.

So after that long explanation… Am I doing this correctly? OR Is there a solution that can create and rebuild a tree without making a new AUParameterTree object?

If I can do that the host in question may not crash, ( although it might anyway because all the parameters have changed ).

I have posted a code example to the host developer but sadly got a response which gave me the impression he was not prepared to work on a fix.

Thanks!

Answered by NikoloziApps in 210699022

Pretty sure replacing a ParameterTree is a supported feature. And it seem only way to rebuild it is to fully replace it. This is from the headers:

"The tree's elements are mostly immutable (except for values and implementor hooks); the only way to modify them is to publish a new tree."

I'm curious, which host is crashing?

I don't see how holding on to an old AUParameterTree object would cause a crash. Unless the host code that keeps a reference uses __unsafe_unretained.

Boost

Answer 1

ParanoidAndroid OP

Feb ’17

no one?

0

Answer 2

NikoloziApps OP

Feb ’17

Accepted Answer

Pretty sure replacing a ParameterTree is a supported feature. And it seem only way to rebuild it is to fully replace it. This is from the headers:

"The tree's elements are mostly immutable (except for values and implementor hooks); the only way to modify them is to publish a new tree."

I'm curious, which host is crashing?

I don't see how holding on to an old AUParameterTree object would cause a crash. Unless the host code that keeps a reference uses __unsafe_unretained.

1

Answer 3

ParanoidAndroid OP

Feb ’17

Yes, that confirms my thoughts on the matter too, thanks Nikolozi.

r.e. which host: I'd rather not name names at this stage, I'm hoping it will get fixed!

What I do know is that it crashes after the tree is rebuilt and published. The developer has confirmed that the tree is not being refreshed after the first query at AU launch time, i.e. it's ignoring the new trees when they are published, so I guess there's a 100 reasons why a crash could happen!

0

Answer 4

ParanoidAndroid OP

Feb ’17

Update:

The host developer got back to me in the end and it turns out I didn't test this as thoroughly as I had thought. It seems that all hosts will eventually crash after the parameter tree is changed and an exception is being thrown in iOS... looking for a solution, will file a radar bug report maybe ...

0

Answer 5

NikoloziApps OP

Feb ’17

Would you be able to post a stack trace of the crash? I'm curious as to what's happening. I haven't needed to update ParameterTree in my apps yet, but I imgaine I might need this feature at some point in the future.

0

Answer 6

ka010 OP

Mar ’17

Hi guys,

I've run into the same issues with pretty much all hosts and was just about to start contacting them when I found this. Any updates on this?

EDIT: I should add replacing the parameter tree does not immediately crash the hosts, usually it's accessing the plugins presets what's causing the crash which makes sense given doing so would make the host access the parameter tree.

0

Answer 7

benkamen OP

Sep ’17

Has there been any news on this? Is it just that host apps aren't properly supporting it?

0

Answer 8

ParanoidAndroid OP

Sep ’17

Sadly, even with the release of iOS 11, nothing's changed so far.

I've decided to implement a work-around that negates the need to supply a dynmanically changing parameter tree. It's a shame that host developers and Apple have not picked up on this issue so far. Perhaps it needs more of us to make more noise about it?

My work-around involves supplying a fixed number of "Global Automation" params in the tree and having those mappable internally to the dynamic parameters in the engine with the map saved in the AU's preset data. ... Not sure how well this will pan out ... will report back if/when it's done! ...

0

Answer 9

pacomacman OP

Jun ’20

Did you ever get a solution to this problem. I'm having similar issues myself on my latest project which attempts to rebuild the parameterTree. AUM handles it perfectly, but GB seems to stop calling my tree.implementorValueObserver function after the tree is modified. Ironically implementorValueProvider is being called just fine.

You mentioned another method of mapping internally, can you elabourate on that and how you got around this issue?

0

Answer 10

NikoloziApps OP

Jul ’20

Would love to know what the state of AUParameterTree recreation is on the latest iOS. Might need to start using it later on. I'll report what I find.

0

Answer 11

ParanoidAndroid OP

Aug ’21

The documentation appears to have been updated recently....

  An audio unit may choose to dynamically rearrange the tree. When doing so, it must

	issue a KVO notification on the audio unit's parameterTree property. The tree's elements are

	mostly immutable (except for values and implementor hooks); the only way to modify them

	is to publish a new tree.

But sadly it seems most of the important hosts don't appear to respond to the notification and so it's probably not a good idea to change the tree after it's created.

0