VCV Rack running native on Apple m1

VCV Rack
42

SquinkyVCV now running here in native M1 build. Thank goodness for the sse2neon header. :slight_smile:

IIRC the Surge-Rack compile errors were similar, Iā€™ll tackle it next.

1 Like
43

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)?

44

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
45

You just need to add it to your include flags.

1 Like
46

Those warning about options are always there on Mac.

47

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
48

ā€œ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.

49

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%
50

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.

51

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
52

Actually now, when using the newest M1Ultra chip? Seems like weā€™re watching superhero movies in CPU form these days. :slight_smile:

But letā€™s not forget, itā€™s very very cool to have Rack running native on the new ARM Macs.

53

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
54

Reaper also can load Intel VSTs and is ARM64 native

1 Like
55

So the ARM version of Reaper can load Intel VSTā€™s? Any word yet on the stability and performance of this?

56

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
57

Yes, agree.

58

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
59

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,

60

Is that a native/ARM/M1 version of Reaper?

61

Have tried with both - non-native Reaper under Rosetta, and ARM /M1 native which bridges intel vstā€™s.