What are DAWs reading when scanning the plugins folders?

[Fender19]

When I attach Logic Pro X to the debugger in Xcode it shows that my AU plugin's constructor is not called until the plugin is actually loaded onto a track. Scanning the plugin in Plugin Manager shows no action, i.e., a hitpoint at the constructor is not triggered.

So if the plugin constructor is not being called during plugin scanning what are DAWs reading that tells them the I/O configuration capabilities of the available plugins? Is there some other function or header file that provides the plugin I/O information?

How, exactly, does this work?

[syntonica]

As far as I recall, auval and DAWs do instantiate the plugin and poke it with numerous sticks.

[Vokbuz]

AudioUnits have all required info in the Info.plist file. There is no need to instantiate plugin to get its information.

For I/O instantiation required and it should be done.

[Fender19]

As far as I recall, auval and DAWs do instantiate the plugin and poke it with numerous sticks.

That's what I thought too - so then why doesn't it show that in the debugger? I don't see anything happening until the plugin is actually loaded in a track.

[Fender19]

AudioUnits have all required info in the Info.plist file. There is no need to instantiate plugin to get its information.

I don't see any plugin I/O configuration info in the plugin's Info.plist file - only build and version data.

[Fire Sledge - Ohm Force]

That's what I thought too - so then why doesn't it show that in the debugger? I don't see anything happening until the plugin is actually loaded in a track.

Probably because the host uses a separate process to collect the information. If the plug-in crashes hard because of some issue (missing resource, dongle, poor implementation, etc.) this doesn’t crash the host.

[Fender19]

That's what I thought too - so then why doesn't it show that in the debugger? I don't see anything happening until the plugin is actually loaded in a track.

Probably because the host uses a separate process to collect the information. If the plug-in crashes hard because of some issue (missing resource, dongle, poor implementation, etc.) this doesn’t crash the host.

Any tips on how to debug it in that case?

[Jeff McClintock]

That's what I thought too - so then why doesn't it show that in the debugger? I don't see anything happening until the plugin is actually loaded in a track.

Probably because the host uses a separate process to collect the information. If the plug-in crashes hard because of some issue (missing resource, dongle, poor implementation, etc.) this doesn’t crash the host.

Any tips on how to debug it in that case?

Scanning a plugin is pretty quick, so you usually don't have the opportunity to attach a debugger. In this situation, I sometimes temporarily add a dialog box to the plugin's constructor. What this does is pause the plugin and give you the time to attach a debugger.

[MadDogE134]

as far as i know the DAW is just looking for a 'listing' to place in it's browser although in Studio One for instance during the scan it also looks for validation of the plugin like ilok returned response or checking if demo items are current or expired. i don't think it is an actual 'call' for the plugin... just scans attached info

[Fender19]

i don't think it is an actual 'call' for the plugin... just scans attached info

What attached info? There is nothing in the plugin Info.plist about plugin I/O capabilities.

How does the DAW "know" if a plugin is mono or stereo, has side chain capability, etc.? Somehow the DAW determines that BEFORE the plugin is loaded into a project - so the DAW displays the plugin in the applicable channel FX lists, etc.

This is baffling! How does it work?

[lkjb]

Why don't you write some log output to a file and have a look at said file after running the plugin scan.
It is also possible that the DAW and even Plugin Manager doesn't scan the plugin again as long as it hasn't change. For that the plugin file's timestamps, size and even version could be checked.

Regarding debugging a plugin scan: I remember vaguely that this won't work if the scan is done by another process. I think I ran into this when trying to figure out why auval wouldn't validate a plugin in Logic but had to run auvaltool instead of Logic for debugging. Nowadays you have to copy auvaltool to some location where you can actually select it for debugging but luckily, I haven't had to do this for some time so I'm not sure.

[Fender19]

Regarding debugging a plugin scan: I remember vaguely that this won't work if the scan is done by another process. I think I ran into this when trying to figure out why auval wouldn't validate a plugin in Logic but had to run auvaltool instead of Logic for debugging. Nowadays you have to copy auvaltool to some location where you can actually select it for debugging but luckily, I haven't had to do this for some time so I'm not sure.

Yes, I did that with auvaltool and now I can see what's happening in auvaltool. However, some plugins that PASS auval FAIL in Logic. That is what I'm dealing with right now. I can't "see" what's happening in Logic before the plugin is actually loaded onto a track to understand what's preventing it from loading.

[quikquak]

It seems silly and somehow old fashioned, but have you tried rebooting the computer?
Logic tends to cache a lot of things.

[Fender19]

It seems silly and somehow old fashioned, but have you tried rebooting the computer?
Logic tends to cache a lot of things.

Yes! Cleared AudioUnitCache as well.

I understand that auval does not check for sidechains. So it is entirely possible to pass auval and fail in Logic if your plugin provides side chain inputs. That is the issue I'm having.

The question I have is how, and from where, is Logic getting that plugin I/O information since it does not appear to launch the plugin's constructor until the plugin is actually loaded onto a track?

[kryptonaut]

I don't know if it works with Macs, but back in the day on Windows PCs I think you could compile an Int 3 instruction into your code which would trigger a debug breakpoint on execution - it might allow you to catch whatever it is that's calling your constructor?