[Sticky] Will Unify ever run natively on Apple Silicon?

How can I get added to the Unify M1 beta testing group? Also does the current build include any bridging for non-M1 native plugins? If not, can it be used alongside the current release version? I understand if those questions are only answerable in the beta forum.

@e-blue

Send email to John at UnifySupport@PlugInGuru.com to request the M1 beta.

On ARM processors, MacOS already supports automatic bridging of Audio-Unit plug-ins only. Unify has no bridging of its own for VST/VST3.

The stand-alone Unify app can be used alongside the v2.8 installation, but once you install the beta plug-ins (including Unify itself and all the bundled plug-ins), you're stuck with them.

@getdunne Ok, I guess I'm not quite ready for the beta in that case. I haven't even scanned any AU plugins into Unify and also all of my custom subsets point to VST/VST3 plugins and would need to be recreated. My current DAW of choice, Bitwig, runs in M1-native mode and includes bridging of non-M1-native VST/VST3 plugins. I hope that bridging will be a serious consideration as I don't think any of the currently Unified third-party patches will work with the AU-bridging solution.  

@e-blue

I'd love to be able to add universal bridging to Unify, but it's a HUGE job, quite possibly beyond our means.

You are correct that MacOS's in-built AU bridging will not help run Unify run libraries that target VST or VST3 plug-ins.

If Bitwig is your DAW of choice, and it does bridging as you describe, just continue using the existing Intel-only version of Unify. Bitwig will bridge it, and Unify can continue to load all VST and VST3 plug-ins in Intel mode as always.

@getdunne Yes, that's what I'm doing now and it actually work's quite well. However, I'm starting to encounter plugins that don't like running in Unify when it's bridged. For instance, MeldaProduction MSoundFactory doesn't like being run within bridged Unify.

Posted by: @e-blue

MeldaProduction MSoundFactory doesn't like being run within bridged Unify.

Could you report your findings to Melda? Please tell them to contact UnifySupport@PlugInGuru.com to request an NFR license for Unify for testing.

@getdunne This may be useful for continuing to optimize Unify for Apple Silicon:

https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon

@tony10000

Thank you. These Apple documents can sometimes provide useful hints, but my problem is that I use JUCE. All the platform-specific code is buried deep in the JUCE library, is very difficult to understand and even more difficult to change, and worse, any changes I make are likely to get reverted every time JUCE itself is revised.

Hi Shane, 

Congratulations on the Apple-Silicon ready release of Unify. I'm having really good success with it so far. I was able to salvage the x64-bit standalone version by renaming the Mac app before installing 1.8.2. I am now able to load both versions independently. This brings me to a suggestion for providing something similar for the legacy x64 VSTis. Is there anyway that we could get a final legacy release of Unify v1.8.0 which has a different VST identifier? It could be called Unify-Legacy or something.

This would allow DAWs to recognize it as a separate VSTI and we could still load the patches from x64-only VSTs that may never be updated like BreakTweaker, Razer, Largo, etc. It would also be ideal if it could continue using the settings for the normal Unify install. It would also be nice if we could hide libraries in the Apple Silicon release or maybe we could move them to a subfolder that is only read by the legacy version if you decide to release one.

Again congrats and thanks for all of the hard work!

@e-blue

Interesting suggestions. You begin to see just how complicated it is to support Apple's latest architectural changes. We don't have all the answers, and we can't even claim to know what all the issues are. That's why we're classifying this as a "public beta".

The problem with things like "VST identifier" is that every DAW is different in terms of how it will handle such things. I don't even have every DAW to test with, and we could go broke trying to be compatible with everything ever made by other companies.

I am continuing to look into possibilities for how to handle Intel-only VST/VST3 plug-ins on ARM Macs. Your idea is interesting, but there may also be other ways that are ultimately less disruptive.

@getdunne 

I'm doing a bit more testing and I've just discovered a hidden feature of my primary DAW. Bitwig allows you to specify Preferred formats. It will automatically hide VST2 versions if a VST3 version also exists. Similar to what I did with the standalone version of Unify, I renamed the VST versions of Unify 1.8.0 before installing 1.8.2. Initially, the old, renamed VSTs were not appearing in Bitwig. However, after changing the Preferred formats setting to show All plug-ins. Surprisingly, I then saw the renamed VSTs in addition to the VST2 version of 1.8.2. I'm now able to see and load both the old and new versions of Unify simultaneously within Bitwig.

Like you mentioned, every DAW will handle these situations differently. I just wanted to point out a possible workaround for this one DAW. I'm still interested in seeing what you'll be able to come up with in the future.

@getdunne Yikes!  Sounds like quite a minefield!  

Hey @getdunne 

I like to add my voice to the above comments by saying what a wonderful job you have done on the Apple Silicon version of Unify. DAMM is it super silly fast now huh‽! 🙂

I wanted to let you know one thing I've found which isn't a Unify problem as such, but it will cause an issue with purchased PlugInGuru Kontakt/Unify libraries so I thought I'd better post my findings here.

I thought I'd fire up the Unified Del Norte library, but Kontakt couldn't load itself as part of the patch. Interesting I thought, as NI say Kontakt is Universal now. It's not, it's almost Universal!!! The Kontakt Application is, so is the AU component & the VST3 but NOT the VST, crazy huh‽ I used the  lipo command to verify my theory...

lipo -archs /Applications/Native\ Instruments/Kontakt/Kontakt.app/Contents/MacOS/Kontakt

x86_64 arm64

lipo -archs /Library/Audio/Plug-Ins/Components/Kontakt.component/Contents/MacOS/Kontakt 

x86_64 arm64

lipo -archs /Library/Audio/Plug-Ins/VST3/Kontakt.vst3/Contents/MacOS/Kontakt 

x86_64 arm64

lipo -archs /Library/Audio/Plug-Ins/VST/Kontakt.vst/Contents/MacOS/Kontakt 

x86_64

I'm guessing that the VST version will never be Universal due to Steinberg licensing and all of that jazz. I seem to recall that on other libraries you've had to supply them as VST3 patches in order to keep cross platform compatibility as the VST version of the plugin was no longer available... so my question is, do you have an in-house built tool that can take a Unified library and change the VST plugin to point to the VST3 version of the plugin instead therefore keeping cross platform compatibility whilst also keeping Apple Silicon Kontakt compatibility as well? I hope that makes sense!! 

Keep up the good work and enjoy your new house mate, you've earned it big time 🙂

@djtobes

Well, isn't that frustrating! Steinberg has managed to convince people that VST3 is somehow sufficiently better than VST2.x, that even major plug-in vendors like Native Instruments are starting to drop support for the latter. I'm pretty sure this is not a licensing issue, and it just goes to show what a mess results from the need to support multiple, proprietary formats in the first place. This is one of the reasons I'm hoping the unrestricted CLAP format takes off.

It might be helpful if you were to inform NI directly about this, explaining how unified libraries require a specific format (in this case VST2.x), and so for them to choose not to make the Kontakt VST universal causes a substantial loss of capability for you. In my experience, they're quite responsive, especially the Kontakt team. This might just be an interim stage for them, and perhaps they will eventually provide universal versions for all formats, especially if customers request it.

Fair point man, will do! 🙂

Great to see this AS native version. Thank you, Dr. Dunne!

Is there a way to change the UI of Unify in Pro Tools?

There was a CPU on M1 spike avoiding tip in one of Skippy's last videos... something to mark in Unify's settings.

I can't find it anymore. Will it solve the problems?

I have spikes as hell... made some combo orchestral instruments using one Kontakt7, one Audiomodeling instrument, a Fabfilter Q3 and a Valhalla Room in a Unify instance. I can't play monophonic lines without crackling. And I need about 50 of those instruments. It was demanding but doable on my previous Intel Mac. That's why I bought the Ultra... :-/

@saxer 

Check the box "Max Thread Priority (experimental)" at the top right in Settings. On an M1 Ultra Mac it should be checked by default. Please tell me if it was not.

This spiking behavior is affecting everyone using M1 Ultra, and the whole audio industry is mystified about what's causing it. It's not only Unify that is affected. What we do know is that it's not about the Ultra being "less powerful" than an Intel CPU; it seems to be something very subtle. I'm very sorry Unify is giving you grief on your new machine. I'm confident we'll track it down eventually, but I can't predict when.

Which DAW are you using (or are you using the Unify stand-alone app)? What are your sample rate and buffer size settings? You can usually reduce CPU issues by increasing buffer size to e.g. 512 or even 1024.

Posted by: @kbonded

↑

Is there a way to change the UI of Unify in Pro Tools?

Sorry for the late response. I didn't see this until now. (Sometimes this forum software does really weird things.)

You probably have Unify's GUI Size set to something other than 100%. Try running the Unify stand-alone app, set it to 100%, then quit and load up the Unify plug-in in Pro Tools again, and it should look correct.

Hi there! Any updates or timelines on performance with M1 Pro chips? Unfortunately, I still get clicks and pops even with the Max Thread Priority checked.

Thanks a lot

Posted by: @pzoo

↑

Hi there! Any updates or timelines on performance with M1 Pro chips? Unfortunately, I still get clicks and pops even with the Max Thread Priority checked.

Unfortunately, not yet. This is a known issue deep in the JUCE platform that Unify is built on. It appears that a solution is in the works, so with luck, we'll be able to incorporate it into the next release of Unify.

@getdunne understood.  Thanks for the update. Fingers crossed!

@getdunne have they find in juce the problem ?. maybe the fault in juce or unify is that it access USB stuff inside audio hook. what does the blue lines tell exactly that is in right half of cpu meter ?. ?

from  earlier i have written that after hibernate and then return unify do hangs. I notice this problem now even more when i use unify in mulab 9. this do also on mme driver 0.1 sec hangs. I have install windows 11 on other drive fresh and this do same. when i have most usb devices remove then the blue line come selden. blue line right and cpu spice on left side come always for few seconds when i plug in or remove a usb device. the cpu meter of studio one does not change when i plugin or remove a usb device and unify is not enabe. but as soon unify is used even if play no notes  i notice a cpu spike when i plugin or remove a usb device. so i assume juce do some usb access in audio thread edit: when i go with mulab on in standby i also test stop mulab audioengine by go to audio settings. does not help sooner or later hangs happen.

@user476565

This forum topic is specifically about multi-threading on newer ARM-based Mac computers. The JUCE developers are aware of the issue, but have not yet added support for the new threading API's which are required to solve it.

Please make a separate forum topic with your observations about Unify on Windows. Whatever may be causing these issues, it has nothing to do with the specific issues found on Mac M1 Pro/Max/Ultra machines.

There is no fix yet for the current version of Unify, right?
I switched from Windows to Mac just a few weeks ago, running an M1 Max Macbook. I also encountered the CPU spikes while running Unify in a native Apple Silicon Cubase 12 session. Very frustrating since I used Unify a lot before the switch and all my patches are now having CPU spikes. Especially used it a lot for Spitfire BBCSO and SINE Player custom patches.

@myuusic

Unfortunately, no, there is still no fix for this. Make sure you go to Unify's Settings view and check the "max thread priority" box.

It would be VERY helpful if M1 Pro/Max users could share any observations here about what makes the CPU spiking better/worse. This could help others, and possibly also suggest where I might look for a solution.

I see the Max Thread Priority box checked by default, but only on the standalone version of Unify. It is not visible in the plugin version. If I see anything how the spikes can be somehow controlled, I'll gladly share it.

I've run into bug with Roland Cloud and Unify (STD v1.9.1) on a M1 Max MacBook Pro.

Certain synths, the D50 for instance, just draws a black box. The box is the right shape and size for the D50. The synth still sounds but you can't change patches. This doesn't happen on my Intel iMac only on my M1 Max MacBook Pro.

I don't have this problem when using Reason 12 and here's where it gets weird. If I open Unify inside Reason 12 the D50 displays OK as do all the other instruments that are in Roland Cloud.

I'm not sure if this is a big issues as Roland has started updating some of the instruments in Roland Cloud and they don't have this problem.

Jack...

System info:

 Model Name: MacBook Pro

  Model Identifier: MacBookPro18,4

  Model Number: MMQX3LL/A

  Chip: Apple M1 Max

  Total Number of Cores: 10 (8 performance and 2 efficiency)

  Memory: 64 GB

  System Firmware Version: 8422.100.650

  OS Loader Version: 8422.100.650

@jack4

Graphics issues have consistently plagued certain plug-ins over the years. I suspect Roland are aware of this already, but I'd still suggest you report it to them.

One other thought: could you please try running Unify in Rosetta mode (do "Get Info" in Finder and check the Rosetta checkbox), and let me know if the problem persists?

@getdunne 

Sorry I didn't even think of the Rosetta check box. That solved the problem, all the Roland Cloud instruments now display correctly.

Thanks for the quick response!

Jack...

Safe to assume no M1 Pro fixes yet in the new version? Thanks

Posted by: @pzoo

↑

Safe to assume no M1 Pro fixes yet in the new version? Thanks

Unfortunately, no. I'm still waiting for an official solution from the JUCE development team.

I was ready to purchase Unify, First tried in a iMac Pro Intel everything great, but when tested in my MacBook Pro 14 (M1Pro) (Camelot Pro as host, in native and Rosetta mode)

noticed CPU spikes all around, making it unusable for a live setup.

I guess you should warn people in the main Unify page about these issues, not everyone feels necessary to dig in a product's forum before making a purchase

Posted by: @jaben1

↑

I was ready to purchase Unify, First tried in a iMac Pro Intel everything great, but when tested in my MacBook Pro 14 (M1Pro) (Camelot Pro as host, in native and Rosetta mode)

noticed CPU spikes all around, making it unusable for a live setup.

I guess you should warn people in the main Unify page about these issues, not everyone feels necessary to dig in a product's forum before making a purchase

I'm sorry to hear that you're struggling with this; thank you for reporting your experience. Did you test only the Unify Demo? If you require a refund for the full retail product, please email UnifySupport@PlugInGuru.com.

M1 Pro/Max/Ultra systems do exhibit some CPU spiking, especially when Unify is very lightly loaded. We still do not have a final solution for this. Did you test running actual presets? If the spikes are still serious enough to make Unify unusable for you, it would be great if you could report this to the Camelot dev team. I'd be happy to work with them if I can get a referral.

First of all, thank you for this fabulous software, recently purchased. I am mainly a Logic (10.7.8) user on M1 MAX 32GB. Like others, I've also noticed the high processor load with a single instance of UNIFY, which increases when loading a patch, and it also seems to me that the load isn't distributed over all the processors, only 2, I did see the "Max thread Priority" box in the standalone application, but not in the VST. My way of making this playable was to increase the buffer size (for my part to 256 samples). That said, the JUCE problem is common to other plug-ins using this architecture, such as those from The Usual Suspects for the plugin Vavra and Osiris, using emulation of the DSP56300 chip. Let's hope that JUCE will be better adapted to Silicon 🙂

@getdunne Sounds like it is related to this:

Aug 2022
I hate to re-open this discussion, but given that I just saw recent
postings about how threads on M1 processors might get allocated to
e-cores instead of p-cores, and since there appears to be no control
over thread priority through JUCE Thread on Apple Silicon (assuming
what was mentioned in FR: Thread-Priority vs Efficiency/Performance
Cores 6 is correct) - is it possible that some of my audio processing
threads got assigned & dropped priority to e-cores and then were
impacted by other e-core threads at same priority such as graphics
refresh related threads - thus holding up completion of my audio
callback tasks? This might explain why graphics repaint related code
appeared to severely impact the audio processing load on my M1 builds
and not on the same Intel Mac build.

https://forum.juce.com/t/m1-based-mac-audio-load-worse-nearly-2x-higher-after-move-from-juce-6-07-to-6-14-but-not-a-problem-on-intel-mac/49968/14

I hate to be that guy that repeats himself (well at least it's been 2 months ago the last time I posted in this thread), but I beg you to find a solution for this. There's not even a workaround that I think works all the time for me. It doesn't matter if I load a whole set of BBCSO Pro strings or just two little Kontakt instruments. The spikes are all the same as far as I can tell. I wish I could use Unify again normally inside my DAW and not like "ah let's try if this patch sounds good and then rebuild it without Unify" because otherwise my project has constant CPU spikes.

• Posted by: @getdunne

  ↑

Posted by: @pzoo

↑

Safe to assume no M1 Pro fixes yet in the new version? Thanks

Unfortunately, no. I'm still waiting for an official solution from the JUCE development team.

Any ETA on this? I don’t like CPU spikes on my M1Max. I guess (and hope) M2 is free of this problem?

Posted by: @fleer

↑

Unfortunately, no. I'm still waiting for an official solution from the JUCE development team. 

Any ETA on this? I don’t like CPU spikes on my M1Max. I guess (and hope) M2 is free of this problem?

There is no such thing as an "ETA" in software development, especially when one is at the mercy of a third-party platform developer. The latest Develop branch of the JUCE 7 framework shows 290 new commits, not one of which appears to address this.

It might help if you could complain about this directly to the JUCE team here: https://github.com/juce-framework/JUCE/issues

Posted by: @myuusic

↑

I hate to be that guy that repeats himself (well at least it's been 2 months ago the last time I posted in this thread), but I beg you to find a solution for this. There's not even a workaround that I think works all the time for me. It doesn't matter if I load a whole set of BBCSO Pro strings or just two little Kontakt instruments. The spikes are all the same as far as I can tell. I wish I could use Unify again normally inside my DAW and not like "ah let's try if this patch sounds good and then rebuild it without Unify" because otherwise my project has constant CPU spikes.

I hear you, and I only wish there were something I could do about this. See my response to @fleer above.

Are you using the "max thread priority" checkbox in Unify settings, AND a buffer length of 256 or more?

@getdunne Is there a possible fix in here somewhere?:

https://forum.juce.com/t/mac-m1-thread-priority-audio-workgroups/52188

@getdunne Will do!

Posted by: @tony10000

↑

@getdunne Is there a possible fix in here somewhere?:

https://forum.juce.com/t/mac-m1-thread-priority-audio-workgroups/52188

Yes, that's the correct direction. I have been following wavesequencer's posts, and he and I have had some fairly extensive discussion on this. His work-around (which will become obsolete as soon as the JUCE team releases their own) is not practical for Unify--and I know, because I've tried it. In a synthesizer plug-in like Wavesequencer Hyperion, all of the multi-threading occurs within the plug-in, and hence the thread management code is fully under the control of the plug-in developer. In a combination plug-in/host like Unify, some of it is within the JUCE framework, which is extremely dense and difficult-to-understand code, so I prefer to wait for the official solution.

The other reason I prefer an official solution is that, however it is programmed, it will require intricate platform-specific code, and at least two distinct implementations will be required: one for MacOS, one for Windows.

That official solution, BTW, was reported as "going through the final staging of review and, hopefully, ... available sometime next week!" back in September of 2022. ( https://forum.juce.com/t/mac-m1-thread-priority-audio-workgroups/52188/12) This is what we are up against. The JUCE team, though highly capable, is quite small, and they have MANY more issues to deal with than this.

Posted by: @getdunne

↑

It might help if you could complain about this directly to the JUCE team here: removed link

What exactly should we say? I assume it’s to complain about JUCE and not Unify