SquinkyVCV now running here in native M1 build. Thank goodness for the sse2neon header. 
IIRC the Surge-Rack compile errors were similar, I’ll tackle it next.
1 Like
What specifically did you do to get it to build? Just asking in case I can apply to other plugins (looking at Valley just now)?
I grep’d for any file including *mintrin.h then added a define for the M1 architecture and a header for the Neon stuff. For instance, in SquinkyVCV-main/dsp/third-party/src/SqMath.h this
#include <immintrin.h>
becomes this
#if defined(__aarch64__)
#include "sse2neon.h"
#else
#include <immintrin.h>
#endif
I put the sse2neon header into each directory where it was needed. Brute force, I’m sure, but I’m just hacking this stuff.
The build continually issued warnings about not supporting these flags in the Makefile
FLAGS += -finline-limit=500000 -finline-functions-called-once
so I commented out the line.
IIRC that’s all I did, I hope it helps. Btw, I was also unable to build the Valley Audio plugin. Good luck !
1 Like
You just need to add it to your include flags.
1 Like
Those warning about options are always there on Mac.
I’m not saying it’s necessarily correct, but I managed to get Valley to build with the following patch. Loads and sounds fine to me. From testing a few monster patches, ARM version seems to use about 2/3rds of CPU of the intel version, nice one!
patch.txt (346.3 KB)
2 Likes
“ARM version” of what? Rack? Valley Audio plugin? The preliminary results from Dave P seemed to indicate he got about a 15% improvement on average running patches on the ARM version of Rack+plugins.
Fair point, that wasn’t clear. Usual disclaimers about YMMV and CPU measurements not being very accurate etc. Timing for M1 Mac Mini. Below are average CPU.
Plateau:
- ARM 1%
- Rosetta 1.3%
Regenera Patch
- ARM 33%
- Rosetta 46%
Those are good numbers, better than @dlphillips . I wonder though… I’m guessing that the Rosetta2/Intel builds are the ones from the library and the ARM builds are compiled on your own machine, correct? Because I know Dave’s numbers for both architectures are for Rack and plugins compiled on his own machine, so now I’m wondering whether you’re simply missing the “compiled on my own machine and therefor optimized for it” bonus for the Intel versions, if you follow me. I would be interesting to know whether those numbers would hold up for you, if the Intel versions of Rack and the plugins you used there were compiled on your own machine, or if they would shrink down to about the same 15% that Dave is getting. Only if you have time of course, but it would be a more apples-to-apples comparison, if you see what I mean.
anything less than 2X doesn’t excite me very much. who cares about 30% improvement? By next year that will be below average.
1 Like
Actually now, when using the newest M1Ultra chip? Seems like we’re watching superhero movies in CPU form these days.
But let’s not forget, it’s very very cool to have Rack running native on the new ARM Macs.
Heh… you’re harsher than me Bruce. I told Dave that anything less than a 20% improvement is not worth bothering with, that’s how I would think if I’m Andrew. But yeah, where’s the line that’ll make it worth it bringing onboard another architecture? Because that’s not a free exercise. In some lines of work they’ll kill for a 5% improvement. I don’t know and I’ll acknowledge that it’s somewhat arbitrary.
But performance aside, what will probably turn out to be more of a deciding factor about an official ARM architecture for Rack or not is the Rack PRO customers. When they will start running native versions of their DAW’s en masse on those M1 machines, and loading tons of ARM VST’s on them, will the Intel versions of Rack and its plugins work for them or not? Right now, as I understand it, Bitwig says the ARM version can load Intel plugins but I don’t know how well that actually works and what kind of performance (penalty?) they get. And the native version of Ableton, as I understand it, can only load same-architecture plugins which I would imagine would be the norm for most DAW’s. But it’s speculation at this point of course.
1 Like
Reaper also can load Intel VSTs and is ARM64 native
1 Like
So the ARM version of Reaper can load Intel VST’s? Any word yet on the stability and performance of this?
so far tests have been stable here even with old and long not updated ones. seems fine CPU-wise as well. Those of course run in a wrapper so latency may be a tiny concern, but again, not noticed anything yet
1 Like
Yes, agree.
For one I’m anxiously awaiting at least an AU version of Rack Pro as Logic is my workhorse DAW. Logic does fine with mixed Intel/M1 plugins, but at the moment there’s no AU to VST bridges that support mixed architectures.
Native M1 support would be amazing. I do hope this comes soon-ish!
3 Likes
Running Reaper on an M1Max MBP here, and the Rack Pro VST loads, but it’s pretty much unusable. Even the simplest patch breaks up at anything under a 1024 buffer, though oddly the CPU usage is not terribly high at all. And anything serious breaks up at 1024. I also notice just moving a window - anywhere - when the Rack Pro VST is making any sound causes glitches. The only other VST I have that behaved this way bridged is Traction’s F-em (it now has an M1 build, though I haven’t tested it yet). Everything else bridges fine, almost all even at a 128 buffer. FWIW, the standalone Rack Pro seems fine under Rosetta, though I haven’t stress tested it yet. It’s just the VST that glitches out as far as I can tell so far,
Is that a native/ARM/M1 version of Reaper?
Have tried with both - non-native Reaper under Rosetta, and ARM /M1 native which bridges intel vst’s.