AudioUnit V3 Parameter Observer Token (originator ignored in setValue)

Question

Xcode Version 7.2.1 simulator 9.2

(Engine is started!)

I've set 2 tokens in the controller (Framework)

        parameterObserverToken = paramTree.tokenByAddingParameterObserver { address, value in
            dispatch_async(dispatch_get_main_queue()) {
                    print("\(address) updated with value \(value) (Src Token)")
            }}

        parameterObserverToken2 = paramTree.tokenByAddingParameterObserver { address, value in
            dispatch_async(dispatch_get_main_queue()) {
                print("\(address) updated with value \(value) (Src Token2)")
            }}

Then further I've set the value of a given parameter and originator.

parameter!.setValue(auValue, originator: self.parameterObserverToken!)

Regarding the doc, setting the originator will avoid any notification in the registered callback and so I was expecting to get only a message from parameterObserverToken2 but I got both :s

Thanks in advance

Core Audio

1.6k

Posted by

FAC

Reply

Add a Comment

Answer 1

This sounds like a bug. Have you filed a BR?

Posted by

theanalogkid

Add a Comment

Answer 2

Done here is the id 25659183

Posted by

FAC

Add a Comment

Answer 3

I've run the Instrument app (Last version of AudioUnitV3Example) on macOS (Sierra) and I've noticed that when the slider attack is moved the parameter value is updated with the slider value BUT ,due to the parameterObserverToken, the slider value is immediatelly updated (again) with the value of the parameter.

This double update is not necessarry. I've tried to provide the token originator to avoid the double update but it does not work (parameter!.setValue(auValue, originator: self.parameterObserverToken)).

Do you plan to fix this? It's the same issue I've logged few months ago.

Posted by

FAC

Add a Comment

Answer 4

The bug you filed with ID 25659183 was a framework bug that was fixed for iOS 10. What you posted above does not seem related. The instrument app on macOS is in Objective-C, so I'm not sure where the swift code is from.

However, I just did a test and modifying attackValueChanged:(id) sender from:

attackParameter.value = powf(10.0, attackSlider.floatValue * 0.01 - 3.0);

To:

[attackParameter setValue:powf(10.0, attackSlider.floatValue * 0.01 - 3.0) originator:parameterObserverToken];

Does prevent the parameter observer block from being called as expected. This tells me the framework is behaving correctly. Is this "correct" -- well, depends on the behavior you want in your UI - for example, you may want to "lock" the slider into a specific position(s) on update where you would want the observer called where you would get the value back from the parameter previously set and re-set that possibly adjusted value back on the slider...or, not.

Posted by

theanalogkid

Add a Comment

Answer 5

I've provided the swift code as an example, but indeed here it's Objective-C.

I've tested again and sorry the parameter observer block is called. Here you have what I did on the last version of the AudioUnitV3Example/Instrument:

1) In ../AudioUnitV3ExampleABasicAudioUnitExtensionandHostImplementation/Instrument/OSX/InstrumentDemoFramework/InstrumentDemoViewController.m I've replaced the line 107 as you suggested: [attackParameter setValue:powf(10.0, attackSlider.floatValue * 0.01 - 3.0) originator:parameterObserverToken]; -> Set the parameter's value, avoiding redundant notifications to the originator

2) In the same file I've put 3 breakpoints: 1 line 107, 2 line 63 (observer block) and 3 line 94 (updateAttack)

3) I've run OSXInstrumentDemoApp -> Deployment target 10.11

4) The program execution stopped at line 94 which is ok the first time, so I continued

5) I've moved the attack slider: the program execution stopped at line 107 which is ok , so I continued

6) Then the program execution stopped at line 63 in the observer block, so if the program stop there, we can concluded that the orignator is not ignored then right after the program exectution stopped at line 94 (updateAttack)

Maybe I'm missing something :s

Posted by

FAC

Add a Comment

Answer 6

I confirmed that this does look like a regression. Issue does not occure in 15G1108 but appears again by the time we get to 16B2657. Can you file a bug report for this with the above information as it's super easy to reproduce and also mention that it is a regression. Reply with the bug # and I'll make sure it gets routed accordingly.

Just a note - the text field will never be updated to reflect the slider value change the way this sample was written if you made this change. So you wouldn't actually want to do this even after the bug is fixed.

Thanks!

Posted by

theanalogkid

Add a Comment

Answer 7

Done here is the id #29270664

Posted by

FAC

Add a Comment

Answer 8

Thanks!

Already started working on tracking this down, so your bug may come back to you as a duplicate. I related the original bug as well (even though it was closed) since it could be a change there causing this regression.

Posted by

theanalogkid

Add a Comment

Answer 9

I've checked and the bug/regression is still present. So basically the following method does not work as expected.

func setValue(AUValue, originator: AUParameterObserverToken?)

Sets the parameter’s value, avoiding redundant notifications to the originator.

Could please provide me a status.

Posted by

FAC

Add a Comment

AudioUnit V3 Parameter Observer Token (originator ignored in setValue)

Replies