AU problems: didn't find the component

Hi all,
the first time I want to run mz plugins in AUlab, but it is not showing up.
Searching the forum brought me this:

Is this file available, and if so, where?

Cheers

As the linked post is from 2009 I doubt it has much relevance now. The points you can check are:

  • Is the plugin in /Library/Audio/Plug-Ins/Components (or ~/Library/...); you should also check the size
  • Does auval -a / auval -32 -a find the plugin
  • Is it maybe a 32/64 bit issue (plugin 32-bit, AULab run as 64-bit or vice versa)
  • Do any other hosts find the plugin?

Thanks @ckhf, I am aware of the age, I just had the dimm hope, that it might have been maintained with updates somewhere :wink:

Now I managed to find the relevant piece in the long auval output, it says:
--------------------------------------------------
VALIDATING AUDIO UNIT: ‘aufx’ - ‘FLST’ - ‘Xwcy’
--------------------------------------------------
ERROR: Cannot get Component’s Name strings
ERROR: Error from retrieving Component Version: -50

* * FAIL
--------------------------------------------------
TESTING OPEN TIMES:
FATAL ERROR: didn't find the component

In both cases, with -32 and without


So probably no wonder that AUlab doesn’t show it.
What are the Component’s Name strings? Do I need to do anything after compile to package it?

Edit: I just realize: auval doesn’ validate official apple au’s, so seems something on my auval is broken:

alumine|15:11:14|Components> auval -t aufx filt appl

    AU Validation Tool
    Version: 1.6.1a1 
    Copyright 2003-2013, Apple Inc. All Rights Reserved.
    Specify -h (-help) for command options

--------------------------------------------------
VALIDATING AUDIO UNIT: 'aufx' - 'appl' - 'filt'
--------------------------------------------------
ERROR: Manufacturer OSType should have at least one non-lower case character: 'filt'
ERROR: Cannot get Component's Name strings
ERROR: Error from retrieving Component Version: -50

* * FAIL
--------------------------------------------------
TESTING OPEN TIMES:
FATAL ERROR: didn't find the component

Any ideas?

N.B. the plugin works fine as AAX in ProTools 3pdev and released, also in VST3PluginTestHost

I rebuilt the JuceDemoPlugin from the tip, and now aulab isn’t playing that one either. I am running Mac OSX 10.10 and Xcode 7.2.1

alumine|17:47:41|Components> auval -t aufx Jcdm ROLI

    AU Validation Tool
    Version: 1.6.1a1 
    Copyright 2003-2013, Apple Inc. All Rights Reserved.
    Specify -h (-help) for command options

--------------------------------------------------
VALIDATING AUDIO UNIT: 'aufx' - 'ROLI' - 'Jcdm'
--------------------------------------------------
ERROR: Cannot get Component's Name strings
ERROR: Error from retrieving Component Version: -50

* * FAIL
--------------------------------------------------
TESTING OPEN TIMES:
FATAL ERROR: didn't find the component
alumine|17:51:42|Components> 

Is there an issue with the AU components with the latest JUCE version?

I think the OS X SDK and deployment targets default to the latest ones (10.11 or 10.12) so your binary simply won’t run on 10.10. Try changing these to 10.10 (or earlier) and build again.

Thanks for the idea, but unfortunately that’s not the case.
The deployment target is set to 10.8, language to C++11 and C++ Library is LLVM libc++
Also the VST3 in VST3PluginTestHost and AAX in ProTools 12 run fine with the same project. Nothing special for AU. Also no Copy protection or 3rd party, only juce code.

I just invested 5$ in garageband, and it shows the jucePlugin and my plugin also.
So I can narrow the problems to AUlab and auval. I filed a bug at apple, that auval does not validate anything on my 10.10.5 System, not even the original apple plugins. Let’s see where it’s getting.

My new plugin shall actually run on logic, therefore i will have to ask my colleague to test that.

I feel your struggle. I think I went to the same and the only reason I can come up with so far is, that logic is a bitch.
Maybe the thread I started helps you, although there is no proper solution yet - at least not for me


Good luck!

Does anyone know the difference between the “-v” and the “-t” auval flags? The built-in help says “’-t TYPE MANU SUBT’ can be used instead of -v option (same optional args apply)”. However,

auval -v aumf Jcdm ROLI

shows no errors, but with

auval -t aumf Jcdm ROLI

I see the same as reported in this thread.

1 Like

Thanks @t0m for confirming that, I almost considered my system broken and scheduled a complete reinstall. That’s a great relief, and validating with -v works for me as well. So I leave it with apple, I filed a bug there, but no response: # 28712630

Now I can move to the problem there :wink:

auval -t or auval -v just changes the order of the parameters. So

auval -t aumf ROLI Jcdm

will work. :wink:

indeed, thanks @fabian
What is weird, now that I checked auval -h and man auval the -t doesn’t even exist. So eventually I picked it up from a web page that I can’t find again. Maybe it was removed after that page was written. But also strange, that -t still does something which is no more documented.

Old versions of auval (PowerPC era) only had the -t option - which was always confusing as the output of auval -a showed them in the -v order. So some wise people at apple added the -v option to be consistent with the output and left -t in for backwards compatibility.

1 Like

may the original error be related to the “PluginWantsMidiInput” parameter?
when I check that component with auvaltool, the “aumf” checks just fine, but “aufx” fails with the error described in the original post. I suppose that is to expect, as the project has only one plist file for one of the types.

I propose an option to add both AU types as an option.
I’m happy to create a pull request for the necessary Projucer changes if there is a chance of it being accepted. Otherwise, I’d just add the second plist entry in my own build script.

Cheers!

Just an FYI for future readers, it may be that auval is failing because of some external environment factors.

I recently discovered that on Mojave, using Iterm as well as tmux all messed up the output of auval. See some bug reports:


Of course it’s possible your plugin is corrupted or some other issue, but I would say try running it from the default Terminal.app in bash and no other modifications (tmux, etc) to see if it works there.

1 Like

This is was it for me, auval behaves weirdly in iTerm2, using Terminal.app fixes it. Thanks!

@regularjack, this also fixed my iterm for me! I am able to run auval successfully inside iTerm.

There has been no fix that I can determine that will fix tmux, however. I have reached out to all parties (apple and tmux) and not found a satisfying answer on either side. Make sure that when you’re running in iTerm you’re just in the “bare shell”, not in any multiplexer like tmux.

According to my contacts at Apple, there is a known bug about it, but no one is working on it at this time.

2 Likes