This post expands on some very good advice I got from James Edward Cosby in the iVCS3 users Facebook group. It goes into a little more detail than he did, and tries to simplify the instructions as much as possible.

Tools you’ll need

  • A text editor, preferably one that has a template for XML (colorizing different stuff helps you keep things in the proper format), can collapse portions of the XML tree, and has regular-expression-based searching. None of these features are essential, but they all save a lot of time, for reasons we’ll see later. The Atom text editor is multi-platform and does all those things, which is why I recommend it. (NB: I just found out that it’s deprecated, but it’s still available, and there’s a fork of it called Pulsar that’s still in active development).
  • A tool that finds problems with XML structure. There’s an excellent one called XML Lint, available at https://xmllint.com/ (incidentally, though it doesn’t say so, the browser-based version supports drag-and-drop for loading files). Hopefully, you won’t need this, but if you do, you’ll find it invaluable.

The process

It’s not really necessary, but as a first step you may find it helpful to make up a bank that contains only a single patch. The XML for a single patch runs to a LOT of lines of text, and while you’re familiarizing yourself with the format it may save you a bunch of time to have an XML file that has only one patch in it.

Techniques for file editing can vary depending on what you have installed and where you’ve installed it. I uploaded all the patch bank files I wanted to merge into Dropbox, so I could work on them with an XML-capable text editor. I suppose that there’s a way to work with them right on the iPad, but I don’t know iPad text editors all that well — feel free to suggest one in the comment section.

To start with, you need to start a new file in your text editor (again, Atom or Pulsar are preferable). You then need to copy-paste this code snippet into it:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>

<!-- patches go here -->

</dict>
</plist>

The next step is to go through all the XML files for the patch banks you want to merge, selecting ONLY the stuff that occurs between the two XML snippets that you see above — just the stuff that occurs in the place labeled “patches go here” (you won’t see that in the iVCS XML files, of course, but I think you get the idea). This is likely to take a while, because — as I mentioned before — iVCS bank files run to a lot of lines of text. REALLY a lot. You need to be careful to get everything that’s contained between the two blocks, and not to get any of the XML that’s shown in the example above.

If you’re being really cautious, you might want to save the merged file after you add each additional bank, and run it through xmlllint. In the worst case, it’d save you a lot of troubleshooting. I didn’t find that to be necessary — but I was very careful to get ONLY the XML I need and not any of the stuff in the two blocks in the example above.

You should DEFINITELY save the merged file once all the banks have been added and run it through xmllint.

One more step is needed. The iVCS3 patch manager does not renumber the patches automatically when it reads in the file. I believe that if it finds duplicate numbers, it disregards the duplicates (not completely sure about that because I haven’t tested it explicitly, but I got an interim result that convinced me that this is in fact the case). So you need to go through and renumber the patches in a consistent sequence, starting at zero and going up by one for each patch in the file. The code snippet that contains the patch number looks like this, and it’s the first line of XML for each patch(the date and time information is a timestamp for when the patch was last changed):

<key>0 - 12.04.2023 | 07:26:44</key>

If you have a lot of patches in your merged file, it’s helpful to have a text editor that can search using regular expressions. For this purpose, all you need to know about regular expressions is that they’re a way of matching patterns in text. We want to match any and all numbers that occur after the <key> (as seen in the example above). A regular expression that will do that is

<key>[0-9]+

which translates to “match <key> followed by one or more integers”. Atom and Pulsar support the use of regular expressions for search — in Atom, you first click on Find in the main menu, and then press the asterisk button to the right of where you enter your search to put Atom in regular-expression-finding mode. You then work through by finding each occurrence, one by one, and substituting the next number in sequence for whatever number is already there. Once you’ve finished that, save the file, and you’re good to go. Assuming you’ve done everything right, you should be able to download the file into iVCS3’s patch banks and everything should work. If not, it’s back to xmllint to see if you can find the problem.

X