AU Plugins Settings Not Saved in macOS Mojave

Anybody else having this issue?

Just noticed that some of my AU plugins have had their settings and saved presets wiped sometime after upgrading to Mojave. This happened sometime between March 2019 and now (August 2019).

I’m using 3.1.1 and just tried loading the song into 3.2.0 as well with the same issue. Some AU plugins have absolutely no problem.

Is there anything I can do to recover the settings?

That is the case if you worked in high Sierra and renoise 3.1.1 and added an au to your Project. The au preset was incorrectly saved then, but you can patch it to make it work again for 3.2, using the copy buffer of the device and a text editor. Fill in the proper IDs in the au preset XML and paste it back to renoise.

Maybe you need to open 3.11 and 3.2 side by side.

I definitely opened and saved this piece in High Sierra. I’m not sure when the presets were lost but it was before 3.2. The presets and settings are wiped in the file using both 3.1.1 and 3.2.

Where do I find the copy buffer for the AU?

Definitely interested in trying this…thanks!

Ok I’ve been digging in the forums and I found all your posts regarding this issue. I’ve copied the buffer text of a working file that saved these presets and settings and compared it alongside a fresh copy buffer of the plugin and also compared it to the broken AU in the song. All of the IDs match perfectly. Am I missing something?

Have a look here: OSX 10.13: AU settings won't be saved/loaded?

First xml is how it will be saved using 3.11 and 10.13++, the second one is how it is correct and 3.2 expects and saves it.

Is that XML from preset saves?

Sorry I was saying the wrong information. These were saved settings inside the song file, not actually a saved preset for the plugin itself.

If you just change the parameters in a plugin instance for a track without saving a preset, doesn’t that just get stored in the plugin instance value parameters in the XML?

Apologies, I’m new to digging into the innards of Renoise…

Have a reading here: Most easy way to replace instr/fx with 64bit version / crossplatform exchange

You also can replace those ids in the song.xml. Do not overwrite the songs with Renoise 3.2 before you fixed it, or the preset will be gone.

I’ll try this.

How do you use the edited song xml file? I’m able to extract the xrns file as a zip, open the xml and edit it, but when I re-zip it and rename it back to xrns, Renoise won’t recognize it as a song file.

C’mon man, please use the search function (i use google with “renoise forum xxx”). I’ll give you one last hint: pack the files without the directory, so the flat files only (and sample dir).

Was able to change the song xml to id the AU to VST version, presets still didn’t come through even though I see the presets in the xml correctly valued.

I’m probably just going to have to hand edit the presets and copy the instrument xml to text to see if I can match the values one by one…

Another interesting tidbit about this that I found through digging around with my old files. Using Time Machine I was able to pull up copies of this song from early May.

4-12-19 - Upgraded to macOS 10.14.4
5-3-19 - Save file xml still retains the original plugin saved instance parameters
5-7-19 - Save file on this date, the parameters are all wiped in the xml, saved to init settings
5-22-19 - Upgraded to macOS 10.14.5

Doesn’t seem to be related to macOS upgrades, Renoise upgrades, or even the plugin upgrades…

You can’t replace a vst into an audiounit preset, those preset formats are not compatible.

  • Load Renoise 3.11 and the song you saved with 3.11/high sierra++
  • Load Renoise 3.2 and put it on another virtual desktop
  • In 3.1, select the au effect or instrument and then left click on the preset selectbox and choose “export preset” (at the bottom of the list)
  • Open a proper text editor, and open the saved .aupreset file
  • Now edit add those values which are missing with the proper ones. If you don’t know which these are, open a new instance of that effect in 3.2, save the aupreset and then open that to another tab of your text editor for comparison
  • After editing, save the aupreset file
  • In 3.2, select the device, click onto the preset menu and choose “import preset”

Editing the song.xml does not work, because the preset data/complete aupreset xml seems to be encoded then into a base64 text chunk, sadly. Maybe a base64 decoder then could do the trick, I don’t know.

EDIT: Damn it, I think I mixed up things a bit here… Sorry for the confusion!

For audiounit, you actually have to save the .aupreset instead copying the whole device. I edited the above text accordingly.

As soon as I try exporting the preset in 3.1.1, I get the following error (which I’ve never seen before):


Here’s a few more things to further complicate this whole scenario (as if we need to get it more complicated)

  • In the 5-3-19 version, the saved settings for the plugin show up in the song xml, but don’t load up when being run in 3.1.1 or 3.2
  • Any file I’ve recovered for this song after 5-3-19 does not have the changed settings data in the song xml
  • This particular query error happens in 3.1.1, but not in 3.2, even when testing a fresh instance of the plugin on both versions

Appreciate all your help on this. These AU issues have been frustrating, to say the least.

Oh wow, never experienced that. I guess then only Taktik can help.

Thanks for the help! I did learn a lot that I wasn’t aware of, which will help me greatly in the future.

1 Like

I’m a bit lost. Not sure I can follow you guys.

If I understand correctly you got a 3.1 song which has broken presets, because it was saved on MacOS Mojave. Is that correct?

As mentioned by FFX, the preset data quite likely is still intact, but only the AU identifiers got broken.
So the only chance to fix this, is to edit the Song.xml file and fix all the AU identifiers manually. Then load up this song in Renoise 3.2. This will be very tendious to do.

@taktik, I think one of the problems is here that the au identifiers of the au presets are in fact base64 encoded into the preset chunk within the song.xml. So the only way to fix it seems to be using export/editor/import.

To simplify, using 3.1 I lost settings data (not preset since I never saved it as a preset, just live settings in the song itself) between 5-3-19 and 5-7-19 after upgrading to 10.14.4.

I just noticed it while loading up 3.2 and looking to make sure all settings converted over to the new version.

The plugin is the AU version of bx_cleansweep v2:

Anyway, if I open the song xml of the 5-3-19 version, the saved settings (on different tracks and samples) for this plugin are in the xml but won’t load in 3.1 or 3.2. Then when I open up the version saved on 5-7-19, the saved settings are gone (on all instances of the plugin) in the song xml.

Neither 3.1 or 3.2 will load up the correct settings with the 5-3-19 version.

I’ve tested this also by making a fresh song file in both 3.1 and 3.2, loaded a new instance of this plugin on the first track, made changes, saved the file and:

  • Both versions retain their settings inside the xml
  • 3.1 version, when loaded in 3.1 and 3.2, the saved settings don’t show up on the plugin instance
  • 3.2 version, when loaded in 3.2, the saved settings DO show up on the plugin instance

To make it a little more confusing, I have a song last saved in 2017 with many instances of the AU version on many tracks, and those settings load up just fine using current version of macOS and both 3.1 and 3.2.

Hope that clears it up a bit, I’ve been doing tons of testing and with @ffx help I’ve learned a ton.

I think you overcomplicating the process. Find a version of your song which loads fine into 3.11, correct preset. Then do what I described above. Also bx-cleansweep is not that complex :smile: Just redo the parameters or make a screenshot of it.

That’s the problem, none of the version with saved presets load up correctly in 3.1. That’s why when I check the song xml on the 5-3-19 version, the saved settings exist, but they don’t on the 5-7-19 version. They disappeared. Loading the 5-3-19 version still bring the plugin to init.

You’re right, bx_cleansweep is very easy to redo the settings by hand, which I have. But I’m bringing this to attention because there is a deeper problem with AUs still, even though much of it has been fixed in 3.2.