I wanted to address a couple of issues that Ben_1 asked about that involved Pro Tools, MacOS, and the GUI Designer. He had issues where it appeared that changes in the GUI designer weren't being saved or propagated into the plugin project. For any MacOS plugin there are some things to remember as the ASPiK XML file is the same across all APIs and it is saved the same way.
First, Ben_1 asked about grey bars on the GUI; Pro Tools/AAX and Logic/AU both have minimum GUI sizes. If the GUI is too small, it will place grey bars on the right and left (I think Logic makes them black) to make the GUI large enough. Note that other clients like Reaper don't do this because of the way the GUI is framed in those DAWs.
Next, there was an issue of saving the XML file, and then having the changes appear, then disappear or other weirdness. There are multiple issues here. When you create a new project, you get a XML file with the Path set to "" (you can find this yourself in the PluginGUI.uidesc file). When you try to save, you will have to do a Save As... - if you try to do a normal save, it will be treated as Save As... because there is no path. Due to a bug in the VSTGUI4 File Save/Open dialog on Mac (they could not replicate it but I could) I do not try to set a default path to the XML file. This means the first time you save, you will need to browse to the proper folder. If you were working on a previous project, when you do the save it will open the same *looking* /resources folder but check the path carefully and make sure you are not saving to a different ASPiK project. Make sure you are saving the correct file and if you have it open in Xcode, then you will see the contents change - check the Path variable and it should be changed.
Another caveat is that the *actual* XML file that the plugin uses (all APIs on MacOS) is in the Resources folder in the plugin bundle. If you edit your file, save it, *then close it (x) and open it again, then open the GUI Designer* all your edits will have seemed to disappear, because you are looking at the old XML file in the plugin bundle, not the one in your project. Now, if you take this new file and save it, you will overwrite your changes. In order to get the new XML file into the Resources part of the bundle, you must recompile the plugin project (this is in the ASPiK tutorial video too). Note that on Windows, you will be forced to do this because the XML file is stored as a compiled resource in Visual Studio.
AAX: because the default AAX plugin folder is admin-protected, I can't write CMake scripts to copy your AAX plugin the same way I do for AU (and Steinberg does for VST3). This means you need to manually copy the plugin from your project's folder to the actual AAX plugin folder (another option is to setup a post build rule in Xcode to do the copy, but you'll need to make sure permissions are not an issue). Several users have made the mistake of not copying the file because they are working quickly and forget - then it looks like your XML file changes were not saved - because you are looking at the wrong plugin.
AAX and AU (and some VST3): when you create the project with the ASPiKreator, you have to enter a 4-character code. It turns out that AAX and AU use this code to distinguish your plugins apart (VST3 clients *should* use the VST3 GUID, but I have seen clients that did not and used the old VST2 4-character "magic" code - which is this code). Some developers, in their zeal to work on the plugins, type either the same value each time, or garbage values that they accidentally repeat - e.g. 'asdf' or '1234' -- this is bad bad bad!!! When Pro Tools or Logic opens your new plugin, it may mistake it for the old plugin and then you will really be screwed up. For example, when Pro Tools encounters two plugins with the same 4-character code, it will only list the last one it finds, and your old projects that referenced the older plugin, will now show the new plugin in the mix window, and the old plugin will be missing from the list.
So the bottom line here is to be careful, check and double-check your paths, and make sure you are not your own worst enemy when working on the GUIs -- I am guilty of all the stuff above, a million times over, so I understand how it feels. Also, if you want to share XML files across different individual (not universal) projects then you need to be careful. The XML file carries around it's own path, and if you share this file to a new project, make sure that you do Save As... the first time you edit the GUI, and make sure you browse to the proper location (double check it!) to do the save.
Finally, backing up your work on a regular basis, or using GitHub to cloud-save your project can really be helpful and a lifesaver.
I'll add that I found a great solution to prevent you from needing to re-add AAX plugins to the Pro Tools folder every time you build (At least on Mac). You can use a symbolic link to add a link to the build file into the protected folder. To Pro Tools, this looks exactly like the file at the other side of the link, and the link is always connected, so every time you rebuild in Xcode, the new code is already ready to go without needing to move it over.
You can't do this in finder, you'll need to use the terminal. Type (without quotes) "ln /pathoriginal /pathtolink". Keep in mind that the pathtolink is a folder, not a filename. The link will be automatically named.
Hope this helps people writing AAX! It's made things a lot faster for me.
Most Users Ever Online: 55
Currently Browsing this Page:
Guest Posters: 1
Newest Members:Jon R., Pat, Jan, Ben_1, shane, teknojunque, David Richter, Nick45, EEkros, Niklas W
Moderators: W Pirkle: 323
Administrators: Tom: 68, JD Young: 80, Will Pirkle: 0, W Pirkle: 323