JUCE, XML, KnownPluginList


#1

I just encountered a problem with JUCE’s XML implementation, exercised by the KnownPluginList. The background is this: Electromagix’s 32-bit Ambience AU plugin (here) uses an AudioComponentDescription subType which contains unprintable, XML-illegal characters (specifically an ASCII 7 at the beginning). That’s legal for an OSType, though.

Since JUCE’s PluginDescription for AudioUnit plugins uses the subType as part of the “file path”, the XML representation cannot legally contain the file attribute for Ambience. However, JUCE’s XML writer doesn’t actually care and writes illegal XML (nor does the reader care about reading it). For ASCII chars < 0x20, only 0x9, 0xA and 0xD are legal XML.

So there are (at least) two issues. First, it would be great if the XML writer/reader could be relied upon to generate valid XML. Second, the AudioUnitPluginFormat might need to be proactive about wildcarding XML-illegal characters, since those will always exercise this problem when the KnownPluginList is exported. Finally, maybe it would make sense to offer a JSON export/import for the KnownPluginList to avoid the issue (although the legacy XML i/o will still need a fix).

For the moment, I’m performing XML-safety validation on my KnownPluginList and removing entries which fail, but it’s not an ideal solution.


#2

Our XML classes do escape all illegal characters! If you’ve hit some edge-case that we’ve missed, can you give us some example code that reproduces the issue?


#3

Hey, thanks for replying. Linked here is a project to reproduce the issue. You’ll need to download Ambience from the link in the original post. Note that Ambience will only load in 32-bit mode (it was never updated to use the 10.7+ AudioComponent API). I’ve also attached the invalid output xml file I get when running the attached code.


#4

Sorry, but can you be more clear about what you mean by this?

The XML file in the zip you sent has escaped characters for the OSType, so looks fine to me.

I haven’t time to install a plugin and try running your app to reproduce it - If you think you’ve found an edge-case in the XML writer, can you just give me a line of code that creates an XmlElement which gets written incorrectly? Because I find it hard to believe that this doesn’t work:


#5

If you run that XML file through a validator, or try to load it using expat or similar, it will fail. For instance, at https://www.w3schools.com/xml/xml_validator.asp

This page contains the following errors:
error on line 5 at column 60: xmlParseCharRef: invalid xmlChar value 7

or at codebeautify.org/xmlvalidator:

Error on->  Line :5 Column :60
Message :xmlParseCharRef: invalid xmlChar value 7

In XML 1.0, even escaped versions of non-printable characters < 0x20 are illegal, as far as I can tell.