Hi Paul and all,
While testing on Ardour an Audio Unit plugin I’m developping, I noticed a problem: some parameter won’t appear in the “automation” submenu, depending on their unit as declared in the AudioUnit source. Among the 27 possible units provided in the Audio Unit SDK, 14 are successfully recognized by Ardour, 12 aren’t, and 1 makes Ardour crash (see excerpt of the crashlog below).
PS: Some extra information:
. my configuration: os 10.6.3 with Ardour 2.8.7 (6630)
. the list of parameter units that work (as defined in “AudioUnitProperties.h” in the Apple SDK):
. the list of parameter units that do not work (i.e. the parameter won’t appear as automatable):
. the parameter that makes Ardour crash is the last one, i.e.
kAudioUnitParameterUnit_CustomUnit. Here is an excerpt of the corresponding crash log:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x980c5413 CFStringGetCString + 131
(in the crashed thread there’s only one function appearing)
Hmm the one that is making things crash(CustomUnit), does it work in anything else(With your code obviously)? It seems like an invalid pointer is being passed causing the CoreAudio libs to try to access something non-existant.
PS This should be logged in Mantis as well.
Wait, actually, I checked with other hosts, and the crash things also occurs on AUlab and Logic for instance. So this second bug seems to come directly from the core audio API. It does not come from my code, since it also crashes with the basic template provided by apple (see below). Anyway it’s not our business any more.
But there’s still the first problem remaining: I don’t have access to the Mantis issue reporter, but I guess it should be doublechecked before adding it as a bug.
Anyway I don’t think it comes from my code, since I observed that also with the basic template provided by apple. This is what I did:
1/ create a new xcode project based on “audio unit effect” template
2/ just compile it, without modyfing anything, and add the builded component to your component folder
3/ start a new session in Ardour, create a blank track, and add the newly-builded plugin
=> at this step, the plugin appears, seems to work, but cannot be automated. If you change the unit of the parameter, let’s say, to
kAudioUnitParameterUnit_Generic, Ardour sees it
But there's still the first problem remaining: I don't have access to the Mantis issue reporter, but I guess it should be doublechecked before adding it as a bug.
Click the ‘Issue Tracker’ link in the top menu bar, and just create an account. That will let you go ahead and make a bug report for this, it is good info, though I suspect Paul may already know about it, it is good to get it in there so it doesn’t get lost and can get fixed.
Good to know about that other issue, yea it definitely looked like an addressing issue beyond Ardour’s reaches which is why I asked. Thanks.
@baskind: "won't appear in the "automation" submenu, depending on their unit as declared in the AudioUnit source."
If you read our source, its pretty simple:
d.automatable = !d.toggled &&
!(info.flags & kAudioUnitParameterFlag_NonRealTime) &&
(info.flags & kAudioUnitParameterFlag_IsWritable);
nothing more to it than that :)
@baskind: oh, and you should be googling for other error. I am 99% certain that this is caused by an error in the templates that apple delivered. apparently its been known about for years and they’ve failed to update them. there was a note on the coreaudio API mailing list a couple of months ago about some new templates being available, from somewhere. Apparently, this is one option to use: http://stephan.bernsee.com/BetterCocoaAU.zip
Hi, and thanks for the info. Actually it’s not a cocoa-related problem, since I’m currently only using the generic view, and also since the problem I mentioned does not appear on other hosts.
Actually I think I found the cause for the problem, in audio_unit.cc: just above the line that you mention, Paul, there is this one:
d.toggled = (info.unit & kAudioUnitParameterUnit_Boolean) ||
(d.integer_step && ((d.upper - d.lower) == 1.0));
It would work if info.unit was considered as a flag in the API, but it’s considered as an int. Thus all the ints in the list which second boolean digit is 1 will make d.automatable false, and those correspond to the list I posted before. I guess a possible correction would consist in replacing the ‘&’ by a ‘==’.
I posted this as a bug in Mantis.
By the way, why a Boolean parameter shouldn’t be automated ?
@baskind: thanks for that. Consider it fixed.
Ardour has no support for automation booleans, almost entirely a result of GUI issues. Drawing boolean automation is totally different than drawing continuously valued automation, and we currently do not have any support for this.