Notifications
Clear all
Questions about UNIFY
113
Posts
24
Users
22
Likes
6,878
Views
Topic starter
May 6, 2021 3:38 pm
User @fleer has asked "will Unify ever run natively on Mac silicon (instead of through Rosetta 2)?"
This question came up under an unrelated topic, but it's important enough that I wanted to give it a dedicated topic, because more and more people are likely to wonder about this over the next several months.
The short answer: Unify for ARM would not be able not load a mix of ARM and Intel plug-ins, so wouldn't be much use. To fix this, we would need to add a custom bridging solution. This would take a long time, and other priorities may preempt it forever.
First, a bit of background for those that may not fully understand the issue.
What's the difference? Central processing unit (CPU) chip designs differ in many ways, but the most fundamental is the so-called Instruction-Set Architecture (ISA), which is the collection of basic operations the CPU can carry out, and how they are encoded in memory. Software (apps, plug-ins, drivers, operating systems) prepared for one ISA cannot run on a CPU that uses a different ISA. Intel CPUs use an ISA called x86-64; the new "Apple Silicon" (not silicone--that's synthetic rubber) chips use the ARM ISA. The two are very different, and hence incompatible.
Why does this matter? Most software is written ("coded") in a "high-level language" like C++, which is NOT specific to any ISA, but this "source code" is not executable by any CPU. A special program called a compiler is used to translate the source code into a binary executable file, which is encoded to match one specific ISA, and hence can only run on CPUs that use that ISA. To achieve very high performance, small parts of the original source-code may be rewritten to take better advantage of a target ISA; this is called optimization. Optimizations for one ISA must usually be re-done from scratch for a different ISA.
How can Apple Silicon CPUs run Intel code? Apple has switched ISAs three times, and each time, have had to somehow ensure that their new CPUs can run executables compiled for the previous ISA. The first transition was made easier because the new PowerPC CPUs had built-in capabilities to emulate the older Motorola 68000 architecture. For the second transition, from PowerPC to Intel, they developed the Rosetta software, which works by translating blocks of binary PowerPC instructions into functionally-equivalent blocks of Intel instructions. For the latest transition, from Intel to ARM, they reworked Rosetta into "Rosetta 2".
Why does Apple even do this? Apple charges premium prices for their computers, so they need the best (fastest, coolest-running, most power-efficient) CPUs available. CPU companies must spend outrageous amounts of money to stay at the head of the race to produce the most powerful processors, and over the years, many have simply dropped out. Apple must therefore switch to the current front-runner every time. This time around the front-runner just happens to be Apple themselves.
OK, with those basics covered, let's look at how this applies to Unify.
Unify is a plug-in host. Much of Unify's value comes from the fact that it can load third-party plug-ins, just like a DAW. It would be a lot less useful if it could only load its own plug-ins.
Host and plug-in ISAs must match. This is the crux of the whole matter. Nearly all plug-ins are dynamically-linked libraries, which are chunks of executable code which are dynamically linked into the executable code of the host application. Whatever ISA the host app has been compiled for, it can only link directly to plug-ins compiled for the same ISA, because Rosetta is not smart enough to deal with a mixture of ISAs.
An ARM version of Unify will only load ARM plug-ins. Because host and plug-in ISAs must match, you can either have Unify compiled for Intel, which can run every available plug-in, or Unify for ARM, which will only be able to load plug-ins which are also compiled for ARM. (Apple allows both Intel and ARM versions of an executable to be delivered in a single bundle called a "universal binary", which is why you don't see separate ARM-only versions of plug-ins, but this is just a bit of file-management trickery. There are separate Intel and ARM binaries hidden inside these bundles.)
How does Logic Pro run Intel plug-ins? For a host program to connect to a plug-in built for a different ISA, it must use some kind of bridging technique. The plug-in is actually hosted by an invisible program compiled for the matching ISA, and the host DAW communicates with this invisible second host instead of linking directly to the plug-in. Apple developed their own bridging software for Logic Pro X, which is (a) not available to other companies, but it only works for Audio Unit plug-ins, which we avoid in order to have Windows/Mac compatibility.
Can Unify be compiled for ARM? Yes, but it's not useful. I did it, months before Apple started selling their new M-series Macs, using a special Apple-silicon Mac they provided on loan to developers. It works beautifully, but cannot load any Intel-only plug-ins. How useful is a version of Unify that can only load the few plug-ins that have been updated to universal-binary format, and can never combine them with the others that remain Intel-only?
When will Unify have its own bridging ability? I can't give realistic estimate. I've been working on bridging for a long time (see my NetVST project), but to create a solution that will work as well as anyone would expect will take a lot longer--probably months longer. The bigger issue, though, is that time spent working on bridging is time not spent working on other things, which we and our customers (especially Windows users, for whom all of this is meaningless) would value more highly.
May 7, 2021 9:13 am
Quite interesting read, Shane, even for me as a Windows user.
Thanks for taking your time to elaborate on this so straight and detailed at the same time. 👍
Lowell reacted
May 9, 2021 8:40 am
I think if unify core run native or not give no speed enhance, because all time consuming thing is done in the plugins. only maybe the guru sampler or effect plugins can get i guess 1-3% speedup when they run native. I think this speedup is not much because today all CPU use a set of most used risc instructions all CPU have. X86 is cisc architecture but only few instructions are use in today compiler, because only this is fast. Intel and AMD have a built in CPU core more or less slow CISC to RISC translator which is only here to be compatible. so it is possible that 1 intel CISC instruction is slower as the 4 used RISC instructions need for this function
May 14, 2021 2:27 am
That bridging project looks pretty, pretty good I must say. Kudos!
May 15, 2021 1:35 pm
Another perspective: now that Unify does so much, maybe it’s time for a simplified Unify Player version or versions (one of which could run natively on Apple Silicon).
June 26, 2021 3:05 am
Which Compiler you use for crosscompiling my husband ask?
Some years ago when he did Initiate the Osirix Project IT was important for him to Go in direction to Mac. This was a stratetic question because medicine world was running with Windows only. This way they keep the big players in distance.
August 30, 2021 1:36 am
Hey Shane, a fascinating read and great explanation. Ahh yes: the complexity of product differentiation. The nerd in me loves to understand, in an overview kind of way, how things work. Too bad Apple won't share its bridging software. Ahh... I always wondered why only AU plugins seemed to work directly in Logic but hey that's why UNIFY fills a unique niche.
October 22, 2021 2:42 am
I wonder if the Bitwig 4 approach could be of any use.
Topic starter
October 22, 2021 1:43 pm
I wonder if the Bitwig 4 approach could be of any use.
What is "the Bitwig 4 approach" ?
October 22, 2021 2:56 pm
I’m no IT connoisseur, but apparently Bitwig 4 runs Apple Silicon native while allowing for Intel based plugins.
Topic starter
October 22, 2021 5:58 pm
apparently Bitwig 4 runs Apple Silicon native while allowing for Intel based plugins.
Actually all M1-native hosts can do this--for Audio Unit plug-ins only--because AU bridging is built into MacOS. If Bitwig can do this for non-AU plug-ins, then unless they publish their bridging code (HAHA), I would have to create something equivalent from scratch.
October 22, 2021 10:00 pm
Oops, don’t think they would 😉
Here’s hoping you’ll get us M1-native anyhow!
November 9, 2021 4:44 am
I would be happy to have an experimental Apple Silicon build, even if it only loads ARM plugins. BBCSO is completely broken on Unify 1.6.x on M1 ... 🙁
Topic starter
November 9, 2021 7:06 pm
I would be happy to have an experimental Apple Silicon build, even if it only loads ARM plugins.
I'll talk to John about setting up a special beta program for this.
BBCSO is completely broken on Unify 1.6.x on M1 ... 🙁
This is because Spitfire has decided to create separate Intel-only and M1-only versions of their plug-ins, rather than follow the Apple-recommended practice of putting both into a single bundle ("universal binary"). You obviously have the M1 version installed, so Unify can't load it.
If you were to uninstall the M1 version, and install the Intel version instead, BBCSO would work correctly in Unify.
Note that for your own patches, you can use the Audio-Unit version of BBCSO instead of the VST; then Apple's built-in bridging will then ensure that it works in Unify.
I'll be the first to admit that neither of these work-arounds is very satisfactory. In an ideal world, Unify would have its own Intel/M1 bridging solution already, but this requires more resources than we can muster at the moment.
November 13, 2021 12:54 am
I would be happy to have an experimental Apple Silicon build, even if it only loads ARM plugins.
That would be great !!! and thank you Shane for your informative initial statement ...
November 13, 2021 9:24 pm
You obviously have the M1 version installed, so Unify can't load it.
Yes I tried their M1 beta for sh!ts n giggles and correct, it does not work.
If you were to uninstall the M1 version, and install the Intel version instead, BBCSO would work correctly in Unify.
Unfortunately that is not the case, as Spitfire BBCSO has an issue with Monterey where the plugin loads but they cannot load any patches whatsoever. Pretty disappointing though - there's no combination of M1 + Unify + BBCSO that works at the moment. I'm sure it'll change soon. 🙂
November 13, 2021 9:25 pm
I'll talk to John about setting up a special beta program for this.
That would be amazing, and I'd love to try it out as you develop it more.
November 15, 2021 12:18 am
How useful is a version of Unify that can only load the few plug-ins that have been updated to universal-binary format, and can never combine them with the others that remain Intel-only?
So I’m setting up my new Macbook M1 Pro for live use with Apple Mainstage as a native host.
Since most of the plugins I’m using (u-he, Blue3, Pianoteq, AAS, Spectrasonix, Falcon, Synthmaster, Melda, Eventide etc) are silicon native now, I think its reasonable to stay native.
*Except* Unify which I’m using in *every* MS-concert.
Given all this, an ARM compiled (preliminary) Unify version (which only loads universal-binary plugins) would be immensely useful for me, I think.
Shane, can you please tell us if we can expect an ARM compiled Unify (test-) version soon ? What would you do in my situation ?
Thanks & best regards
Rob
Topic starter
November 15, 2021 12:46 am
Given all this, an ARM compiled (preliminary) Unify version (which only loads universal-binary plugins) would be immensely useful for me, I think.
Shane, can you please tell us if we can expect an ARM compiled Unify (test-) version soon ? What would you do in my situation ?
I'm working on Unify v1.7, and I plan to make an ARM version of at least the Unify stand-alone app available on request when it ships. Definitely before the end of December, possibly sooner.
Note that many Unify patches require both "built-in" plug-ins like Guru Sampler, MIDIBox, etc. and "bundled" plug-ins like BlueARP, Dexed, all the MDA plug-ins, etc. The built-in ones will get compiled in ARM form along with the rest of Unify, but it will take considerable effort for me to build ARM versions of all the bundled ones. Even the ones for which I have source-code (which is not all of them) are mostly legacy projects which were never designed to be compiled for anything but Intel CPUs. Some may be chock-full of Intel-specific code, and won't compile for ARM without a ton of work. Then there is the very serious question of how these should be installed. My design for where Unify keeps its custom VST folder, etc. was developed long before "Apple Silicon" had been announced, and did not anticipate the need for multi-architecture installs.
What I would do in your situation is continue using the Intel version of Unify and its bundled plug-ins, and not worry about the fact that these and all third-party plug-ins will be running in Intel mode under Rosetta 2. I know it sounds crazy, but I have done tests on my M1 Mac Mini, and verified that the ARM/native versions of CPU-heavy U-He plug-ins like Diva are basically NO FASTER than the Intel versions run by the Intel version of Unify. The M1 processors and Rosetta 2 are honestly THAT good.
However, I understand that no one who has just shelled out for a shiny new M1 Mac will take my word for it, so I will provide an ARM version of the Unify stand-alone for people to test, gain their own appreciation of its limitations, and decide whether or not these are acceptable.
November 15, 2021 2:27 am
What I would do in your situation is continue using the Intel version of Unify
Thank you very much for your instant reply & advice …
1) the Unify stand-alone app will not be of particular use for me since I’m using Unify inside Mainstage in a rather special workflow which cannot easily be replaced by Unify stand-alone. So I would need the Unify plug-in version.
2) I’m aware of “the bundled” plug-ins problem but I for one are not using that much of them (Dexed, some reverbs & delays which could relatively easy be replaced) in my live setup. I absolutely understand that it is practically impossible for you to ARM those legacy code hoping that you will provide an ARM version w/o them.
3) Well, I think I will go with Unify Intel version for the time being …
4) BTW is Unify v1.6.2 Monterey ready ?
Thank you & all the best
Rob
Topic starter
December 2, 2021 5:10 pm
Gig Performer developer David Jameson has just published a very concise explanation of the whole M1/Intel plug-in issue, which applies just as well to Unify as to Gig Performer.
December 7, 2021 3:15 am
Yes! Yes! YES! Unify goes Apple silicon native!
I’m keeping my M1 Mac all-native so this is great news. Will be especially sweet to use the unified BBCSO patches as Spitfire’s gone native too.
Thank you, Dr. Dunne and Guru Lehmkuhl.
Topic starter
December 7, 2021 2:43 pm
Please be aware that you will NOT see another dramatic speed-up, as you saw when switching from Intel to ARM (M1). I have observed essentially no difference in performance for CPU-heavy plug-ins, between a full-native setup (ARM plug-ins inside ARM version of Unify) and Intel/Rosetta (Intel plug-ins inside Intel version of Unify, all running under Rosetta).
However, we cannot fight the tide, so I will be publishing M1 versions of Unify soon, most likely on a "performance not guaranteed" basis.
December 7, 2021 3:16 pm
I know, and I do realize that.
My main reason for only using native plugins on my new M1 Mac (while retiring my old 2012 one) is SSD memory swap, which primarily seems to occur under Rosetta. So it’s not as much for speed than running a pure set up.
Do thank you very much for bringing us this native version, Dr. D!
Topic starter
December 7, 2021 3:18 pm
@fleer I wasn't aware that swapping is worse under Rosetta. Do you have a link?
December 7, 2021 7:58 pm
Not anymore, I’m afraid. Some vids and forums pointed this out. So I tested it myself on my iMac M1. No swaps whatsoever since I’ve gone all native.
January 22, 2022 2:13 pm
1. Thank you for this update and information. Very informative.
2. A limited ARM native Unify would be useful for testing, if not actual production, even if it only runs Omnisphere and limited subset of plugins. Maybe keeping it a permanent beta version until 1-2 years from now when every other plugin and free plugin manufacture has either done a native ARM version, or just given up on Mac.
3. Eventually Apple will drop/disable/cripple/abandon Rosetta 2 in future O.S. releases.
4. I assume Steinberg VST3 is good news/bad news in that it makes more sense to have everything support VST3 and abandon VST2. Unify and Native Instruments Komplete Kontrol are key to my workflow, so this might me a very ugly and messy transition for me. I am 95% mac but do some plugin testing and beta work on windows.
5. Good luck with Unify 2.0.x!! Looking forward to an upgrade (hopefully free or cheap) as well as the suggested additional modules and expansions!
Topic starter
January 22, 2022 3:34 pm
2. A limited ARM native Unify would be useful for testing, if not actual production, even if it only runs Omnisphere and limited subset of plugins. Maybe keeping it a permanent beta version until 1-2 years from now when every other plugin and free plugin manufacture has either done a native ARM version, or just given up on Mac.
We hope to release an M1 version of Unify in 2022.
3. Eventually Apple will drop/disable/cripple/abandon Rosetta 2 in future O.S. releases.
Indeed. If history is any guide, we have about four more years.
4. I assume Steinberg VST3 is good news/bad news in that it makes more sense to have everything support VST3 and abandon VST2. Unify and Native Instruments Komplete Kontrol are key to my workflow, so this might me a very ugly and messy transition for me. I am 95% mac but do some plugin testing and beta work on windows.
My VST SDK license from Steinberg permits us to retain VST2 compatibility indefinitely. I intend to do so as long as possible.
5. Good luck with Unify 2.0.x!! Looking forward to an upgrade (hopefully free or cheap) as well as the suggested additional modules and expansions!
We can't afford to everything for free, sorry. Our policy remains: updates which enable new paid add-on libraries will be free (because the cost of development is at least partially covered by library sales), new features which only enhance work-flow and usability will be paid.
January 22, 2022 4:02 pm
re: above. Shane,
#4 - Is staying with VST2 wise?? I mean, isn't VST3 better (resource management, more modern, better features, more future proof)? I ask out of curiosity as I am way more worried about Komplete Kontrol using only VST2 support than I am worried about Unify. I guess my question is why not cut bait and run now toward VST3 if this is the future for mac and windows?
#5 - paid is fine, I am DELIGHTED and honored to support you guys. The amount of free content you regularly pump out is extraordinary and Unifying my existing investments (Cherry Audio, Spitfire, G-Force, TAL, Omnisphere, u-He, etc.) breathes new life into my home studio. Heck, free TX816 just today! Unify is the most creative tool in my toolbox. I probably own, purchased, upgraded or have acquired licenses, ilok licenses, or NFR to every major software and plugin over the past 20 years. Certainly every relevant or important Mac software except UAD (I own no hardware) and probably 80% of all relevant windows software by default.
Topic starter
January 22, 2022 6:16 pm
#4 - Is staying with VST2 wise?? I mean, isn't VST3 better
VST3 is only "better" for Steinberg. Check around plugin-related forums like KVR Audio, and see what major plug-in vendors like Urs Heckmann (U-He) have to say about the matter.
The shortest way to express it is to say that while VST3 does introduce certain technical improvements, they are implemented in a way which hugely complicates hosting software that must also handle other formats like VST and Audio Units.
I see no reason for Unify ever to stop hosting VST2 plug-ins, and I would imagine that DAW vendors other than Steinberg probably feel the same way. If, some fine day, every DAW in the world stops supporting VST2, we might stop shipping Unify itself as a VST2 plug-in, but the VST3 version would (as I've written elsewhere) become quite valuable as a bridge to allow loading older VST2's.
January 22, 2022 8:52 pm
Gotcha. Good to know. I also don't know how much of this gets covered now with Midi 2.0. I'm a huge u-He fan and it looks like Urs is working on a new plugin format CLAP. Not sure we need another "standard" but interesting just the same. And yes, if I can use Unify as a vst-to-au-to-aax-to-vst3 conversion shell/utility as a format converter with no latency, then that is also great,
From KVR, I guess this also sums it up.
"The original reason for AU on OSX was poor VST hosting documentation from Steinberg, they give out great documentation for making plug ins and almost nothing to host plug ins.
VST3 I would assume adds a whole new slew of problems reverse engineering Stienberg dazzling new format for DAW makers, so almost no DAW maker in OSX anyway is interested in wasting time on it when AU and VST2.4 work perfectly fine right now."
Topic starter
January 23, 2022 3:56 pm
Good point about MIDI 2.0. Probably the most important new feature in VST3 is sample-accurate automation. MIDI 2.0 (which didn't exist when VST3 was designed) provides for real-time control which is sample-accurate, precise, and efficient. It remains to be seen which approach will win in the market.
The CLAP proposal is ambitious. All previous attempts to develop a plug-in standard which is not vendor-driven have failed. I would love to see this one succeed, and I think it has a chance. I'll be following this with great interest.
February 15, 2022 11:50 am
So Shane, to summarise your general recommendation for Mac M1 users for now -
Run your DAW under Rosetta, primarily running VST2's, using VST3 or AU versions when there's no VST2 version available. Like UNIFY.
Did I get it right?
On a sidenote, I appreciate your going into lengths about this, as I'm running Studio One that hosts all three plugin formats. Thank you.
This post was modified 2 years ago by erikhausler
Topic starter
February 15, 2022 3:21 pm
to summarise your general recommendation for Mac M1 users for now -
Run your DAW under Rosetta, primarily running VST2's, using VST3 or AU versions when there's no VST2 version available. Like UNIFY.
Exactly.
May 21, 2022 7:04 am
Is the native version still low priority? I just bought this and even stand alone it's not that compatible with the M1 Air here, Emverb crashes every factory patch it's on here, taking out Enforcer half the time as well.
Topic starter
May 21, 2022 8:52 pm
Unify v1.9 will include ARM-native versions. No release date yet, as we're still testing.
@machinesworking I wasn't aware of any failures with Emverb or Enforcer. Both of those are built-in, so I'd be surprised if they're causing crashes. Please provide some more details of your setup, and post a crash report if you can, so I can see where it's crashing.
Fleer reacted
May 21, 2022 9:37 pm
Unify v1.9 will include ARM-native versions. No release date yet, as we're still testing.
@machinesworking I wasn't aware of any failures with Emverb or Enforcer. Both of those are built-in, so I'd be surprised if they're causing crashes. Please provide some more details of your setup, and post a crash report if you can, so I can see where it's crashing.
Details, just bought Unify, running stand alone in Rosetta obviously on an M1 Air. The factory patches with only the built in plug ins. Patches with Emverb on them open with a nasty pop, and do not play. Muting Emverb usually allows the patch to play, sometimes I've had to mute Enforcer as well. No crash report since it just either doesn't play the patch at all or it's just noise.
Topic starter
May 21, 2022 9:44 pm
Thank you for the details. I will try to reproduce on my M1 Mini here. As far as I know, no other M1 users have reported this yet. I'd be surprised if it's specific to the Air, but anything is possible.
I'm very sorry Unify is giving you grief right after you bought it. Would you like to join our beta test group and try the M1 native build?
May 21, 2022 11:19 pm
Thank you for the details. I will try to reproduce on my M1 Mini here. As far as I know, no other M1 users have reported this yet. I'd be surprised if it's specific to the Air, but anything is possible.
I'm very sorry Unify is giving you grief right after you bought it. Would you like to join our beta test group and try the M1 native build?
There's not too much weird about my setup, but I think I caught the issue. Apologies but it expressed itself very strangely. I'm not sure why this happens but occasionally the RME Babyface here sets itself to 32Khz, for some gawdawfull reason this only affected 'some' patches in Unify and more so with Emverb? probably some Sampler related things I don't know? The odd thing in the setup though is a sometimes shared Fireface 800 that I pipe ADAT in and out of to the Babyface, my guess is the standalone operation occasionally gets screwy and doesn't react like the ADAT slave it should changing the sample rate to 32khz?
Yes I would love to beta the M1 version, 99% of the time Unify is going to be on the M1, in a native M1 host. DP11, Live etc. run too solidly in native for me to want to go back.
Topic starter
May 22, 2022 1:12 pm
Yes I would love to beta the M1 version, 99% of the time Unify is going to be on the M1, in a native M1 host. DP11, Live etc. run too solidly in native for me to want to go back.
I've put you in the "Beta Testers" user group for this Forum. You might have to log out and back in to see the change. You should be able to click on "Forums" at the very top left of the web page and see the full list of forums, including the Beta Testers forums.
The page you want is https://forums.pluginguru.com/postid/13886/
Let me know if you have any trouble setting up the beta. It's basically a process of overwriting the Intel-only binaries the Unify 1.8 installer has already placed on your Mac.
June 2, 2022 12:50 am
@getdunne I would also like to be a part of the beta test if possible.
I'm running Unify on the new Apple Silicon 14" MBP and I'm getting serious popping/clicking noise regardless of the buffer size. Unify seems to be taxing one of my CPU Cores to the max which is odd and it has rendered the plugin almost useless currently. Like the previous commenter, I also tried disabling various effects, but unfortunately, that didn't remedy the situation.
--Lee
Topic starter
June 2, 2022 1:48 pm
I've added you to the beta group for the Forum. See my earlier response to @machinesworking.
I'm hoping to prepare a new automatic installer soon, but I'm incredibly busy with other stuff right now (not Unify related) and may not be able to get to it for a while.
Zastrozzi reacted
Topic starter
June 2, 2022 11:23 pm
I changed my cursor size and color back to normal and all the problems with Unify went away 🙂
Well, that's bizarre, but such things do happen! Thanks for reporting.
Page 1 / 3
Next
