Site navigation

StandaloneFilterWindow not compatible with Introjucer

Audio Plugins
#1

If you want to debug your audio plugin as a standalone application, use (e.g. fork and modify) the juce_StandaloneFilterWindow.h. I really enjoy using it!

But at the moment it is not entirely compatible with an audio plugin generated by the Introjucer.

How to fix it
Either you have to add

AudioProcessor* JUCE_CALLTYPE createPluginFilterOfType (AudioProcessor::WrapperType)
{
    return new TheNameOfYourPluginAudioProcessor();
}

to your PluginProcessor.cpp.

Or you need to change all occurrences of

createPluginFilterOfType (AudioProcessor::WrapperType)

to

createPluginFilter()

in
juce_StandaloneFilterWindow.h.

I’m not very familiar with the inner workings of JUCE, but I guess this changes to juce_StandaloneFilterWindow.h have just been overlooked.
May you fix it, Julian?

Kind regards,
Samuel

#2

Sorry, that does just seem to be an oversight - try it again now.

#3

Thank you for your quick response! Great!

Line 33

extern AudioProcessor* JUCE_CALLTYPE createPluginFilterOfType (AudioProcessor::WrapperType);

and line 163

filter = createPluginFilterOfType (AudioProcessor::wrapperType_Standalone);

also need to be changed.

#4

Sorry, yes - try again!

#5

Just saw that you removed the extern declaration entirely.
I think

is missing.

#6

Thanks!

#7

I think the MAC (Xcode 4.6.2) build might be broken now, multiple error in juce_VST_Wrapper.cpp:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Finder.h:247:3: Use of class template Point requires template arguments

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Components.h:326:68: Reference to 'Component' is ambiguous

AU build seems to be broken too (though the AUBase.cpp file fails, and that’s not part of Juce i think)

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MacMemory.h:130:16: Reference to 'MemoryBlock' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MacMemory.h:132:3: Reference to 'MemoryBlock' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MacMemory.h:133:3: Reference to 'MemoryBlock' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Finder.h:240:3: Use of class template Point requires template arguments

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Finder.h:248:3: Use of class template Point requires template arguments

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Finder.h:261:3: Use of class template Point requires template arguments

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Finder.h:284:3: Use of class template Point requires template arguments

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Finder.h:314:3: Use of class template Point requires template arguments

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Finder.h:327:3: Use of class template Point requires template arguments

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/Components.h:320:68: Reference to 'Component' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/Components.h:412:8: Reference to 'Component' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/Components.h:434:8: Reference to 'Component' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/Components.h:453:21: Reference to 'Component' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/Components.h:468:8: Reference to 'Component' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/Components.h:470:3: Reference to 'Component' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/Components.h:504:3: Reference to 'Component' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/Components.h:560:3: Reference to 'Component' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/Components.h:577:15: Reference to 'Component' is ambiguous

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/Components.h:627:8: Reference to 'Component' is ambiguous

Too many errors emitted, stopping now
#8

No, it’s not broken for me. Must be something about your AU system headers (?)

#9

It looks like this is caused by the usage of precompiled headers. I have a file i precompile that has boost/luabind/juce headers in it. The file juce_VST_Wrapper.cpp is compiled with the flag -include my_pch_file and that seems to be causing this issue. Though it worked a few revisions ago (or maybe in the older Xcode?).

#10

Anyone knows how to make Carbon compile with Juce so i can use PCH again, it really speeds up my build time (10x faster or more).

#12

TBH I wouldn’t actually expect anyone to use the class directly - it’s in the codebase more as an example of how to write one than as a class to be used verbatim. That’s why I didn’t add an automatic include for it, though it’s easy enough to include the file directly yourself (it’s only a single header that you need).

…or perhaps it should always be included, because I guess people do use it just as a quick debugging tool? What do people think?

#14

Hmm. Now that you come to mention it, I’m starting to think I should just move it to the juce_audio_utils module?

#15

(Ah, no - sorry… it couldn’t go in juce_audio_utils because it expects there to be a createPluginFilter() function, which wouldn’t be the case in a normal app).

#16

Yes, I use it as quick debugging tool. But I don’t like the idea of including it.
I’d prefer the Introjucer putting it into the Source-folder if the user wants one. Auto-generated, similar to the Main.cpp and the basic window for a GUI Application.