Logic projects can be shared between the iPad Logic and macOS Logic, provided that the AUv3 plugin on iOS uses the same plugin id as the AUv2 plugin on macOS.
With JUCE plugins, this works only in one direction: using iOS Logic to load a project created on a mac works, but in the other direction, when loading the iOS project on macOS, the ‘JuceAU::RestoreState’ method returns without calling AudioProcessor::setStateInformation :
This is because this line:
ComponentResult err = MusicDeviceBase::RestoreState (copyWithoutData.get());
returns an error code -10851 , and then RestoreState returns.
If I comment the if (err != noErr) return err; , then RestoreState proceeds and everything loads fine. So I guess this is a decent fix for the issue ?
How to reproduce: build the juce AudioPluginDemo from develop branch on both iOS and macOS. Create a Logic Project , change the value of the two parameters of AudioPluginDemo on iOS and save the project, open it on macOS, the edited values are not recalled. If the parameters are edited on macOS, then the edited values are correctly applied in Logic iOS.
The state is a propertylist you can dump it to look at the content. Should be a dictionary with many keys. That might allow you to compare the state between you AUv3 and AUv2 and see what is different.
But the result might be that “downgrading” (AUv3 => AUv2) simply doesn’t work.
I received the following information about the problem (I tried to translate, not sure I did understand it right):
“There is a Juce Data entry in the settings dictionary that makes problems. Because of this we get the error message and do not accept the AUv3 state in our AUv2 on macOS. We have to fix this in the Juce Wrapper. It is an easy fix.”
@reuk They will not fix this. Looks like the problem is JUCE related and we have some minor differences in the AUv2/AUv3 state (settings dictionary) if I understand right. Would be great to have a fix for this soon.
Original response in German:
"Deckt sich mit meinen Beobachtungen. Bei den Plug-ins, die ein iOS Setting auf macOS nicht akzeptieren, gibt es immer einen ‘Juce Data’ Eintrag im Setting Dictionary. Die Fehlermeldung ist auch konsistent. Wenn der Fix im Juce Wrapper so einfach ist, wie in dem Thread beschrieben, dann werden die Hersteller das schnell auf ihrer Seite reparieren können. Wir können da nichts tun. "
This is a more literal translation, from Bing Translator:
"Coincides with my observations. For the plug-ins that do not accept an iOS setting on macOS, there is always a ‘Juce Data’ entry in the Setting Dictionary. The error message is also consistent. If the fix in the Juce Wrapper is as simple as described in the thread, then the manufacturers will be able to fix it quickly on their side. There is nothing we can do about it. "
Bump - we’re getting more and more customer requests to ensure that plugins running on macOS and iOS can restore plugin states and settings across platform (Garageband, Logic).
Before jumping into an investigation ourselves I was wondering if anyone else, or the JUCE team has started to look into this?
FYI, while the fix above works well for the plugin state, automation curves are assigned to the wrong parameters when the project is moved to / from Logic for iPad. I’m not sure why exactly.
Another remark: if you are using dots in your AU parameter names, you’re in for some extra problems because AUv3 refuses parameter identifiers with a dot, so you have to replace them with some other character, which will of course change the identifier hashcode…
I don’t know. To be honest I am now in a situation where I have botched up the automation compatibility of both the VST2 ↔ VST3 and AUv2 ↔ AUv3 when I moved away from the legacy parameter id in JUCE, and started using parameter groups. It is now too late to go back, but I should have kept the good old indexed parameters array, so many things would be simpler…
Not sure if I’m reading this correctly, but it seems that a dot in a parameter key path has a specific meaning for parameters in a parameter group:
Reminder to self to add an assert in our PluginParameter subclass to ensure there are no dots in the parameter ID, and if my interpretation of the dot is correct, perhaps something for the JUCE team to do as well?
Damn, reading this doesn’t give me much hope… I have a plugin that is still also on the old legacy parameter ID system, and I’ve been wanting to update to the newest AudioParameter… stuff, and the thing that has been holding me back is possible compatibility issues… like what you seem to be talking about. I might contact you perhaps at some point to hear which issues you faced, and if you have now-that-I’ve-been-through-this advice perhaps I have another annoying thing with pairs of min/max parameters that can be linked, and I’m not so sure I’ll be able to transplant that into the new APVT stuff.
I would actually also love to hear from the JUCE team what would be the advised steps to (finally) upgrade a plugin still using legacy parameters to the AudioParameter(ValueTree…) system. Probably better for another forum thread though.
We updated all our plugins to the new APTV stuff a long time ago. You can keep the old indexes. There is a flag for this.
Linked parameters are still a problem. You may solve this on the UI.
We had a lot of subtle bugs after the refactoring. The change introduced complexity but there are also a lot of advantages like the included UndoManager and also Parameter Types, listeners and UI attachments.
Not good to hear that automation is broken between AUv2 and AUv3 when using the new parameter IDs. We even have enabled the super legacy parameter flag for the AUs in some of our plugins.
I have another annoying thing with pairs of min/max parameters that can be linked, and I’m not so sure I’ll be able to transplant that into the new APVT stuff.