MacOS build
kmturley opened this issue · comments
I see that your MacOS build is currently disabled:
https://github.com/ryukau/VSTPlugins/blob/master/.github/workflows/build.yml#L47
This means that StudioRack only shows downloads for Linux & Windows
https://studiorack.github.io/studiorack-site/instruments/ryukau/vstplugins/f-d-n-cymbal
The intention of StudioRack is a cross-platform experience, no matter which plugin you pick it will be available to download.
Do you have a timeline for MacOS support?
I don't have any ETA of macOS build. Is it better to drop StudioRack support in this case?
To put it straight, I have a will to support macOS but don't have money to do so. I don't have access to mac, and can't afford one any time soon.
On technical side, the problem is dependency to x86_64 specific SIMD instructions. I'm just started working to add SIMD free code path today, but it's uncertain that plugins will be usable. Removing SIMD means that some plugins may saturate CPU load to 100%.
I also wrote a little memo about the problems around macOS build.
https://github.com/ryukau/VSTPlugins/blob/master/macarmbuild.md
I use a Mac, let me know if you want me to test anything out?
I removed SIMD dependency from most of plugins. I attached macOS build in this comment. If possible, I'd like to know if they can run on some DAW on mac.
Also if you have ARM mac, I'd like to know CPU load of following plugins.
- BasicLimiter with
true peakturned on - L4Reverb
- FDN64Reverb
- PitchShiftDelay
Some plugins are not built on macOS (link), because they require extensive rewrite. I might port them in future but not any time soon. Is it better to omit them from StudioRack for now?
Hi, I have tested macOS build on MacBook Air with M1 CPU (Monterey 12.4). All 20 plugins load and operate correctly in Ableton Live 11.1.5.
CPU usage (1 core) with sample rate 44100 and buffer size 128:
BasicLimiter with True Peak - 21%
L4Reverb - 20-25% in almost all cases, but preset Expertise took 35%
FDN64Reverb - around 37% in all cases
PitchShiftDelay - maximum I've got was 30%
Thanks for testing! I'll package them into next release.
Off topic: It's interesting that M1 + Apple clang seem faster than old Ryzen + x64 MSVC. CPU loads on my environment (FL Studio 20.9.2 on Ryzen 1700) are following:
- BasicLimiter w.
true peak: 30% - L4Reverb: 50%
- FDN64Reverb: 50%
- PitchShiftDelay: 20%
I once got a report that L4Reverb on Intel mac shows similar behavior that it became heavier after loading some preset. Perhaps it is specific to macOS, or laptop with CPU power saving.
PitchShiftDelay causes some spike on CPU load because of the LFO refreshing behavior, and FL tends to ignore those spikes. So it might be just a difference of CPU load indication between DAW.
Also it turns out that adding -mavx2 -mfma or /arch:AVX2 without explicitly using SIMD instructions didn't make any difference on CPU load on my environment. It might be different on more recent x86_64 CPUs.
Hello !
I have been trying to compile them myself a while ago without success.
=> A BIG thank YOU !!! (as always...)
=> I have a M1 so do NOT hesitate to contact me also if needed !!
It indeed works fine under MacOS 12.4 (Monterey) on
- Live 11.1.5
- Max 8.3.1
- Reaper 6.61.0 (seems like it)
Apparently, files should be located directly in the VST3 folder and not a subfolder.
CPU usage (1 core) with sample rate 44100 and buffer size 128
Ableton Live 11.1.5 (native) with m1 max 64 Gb (it should not make much difference from m1):
- BasicLimiter with True Peak - 19-20%
- L4Reverb - 23-25%
- FDN64Reverb - around 32-33%
- PitchShiftDelay - maximum I've got was 9% but @nekotaro6 I guess I missed something here
CPU usage (1 core) with sample rate 44100 and buffer size 128 (which is super short)
Max 8.3.1 (native)
- BasicLimiter with True Peak - 19-23%
- L4Reverb - 39-43%
- FDN64Reverb - 25-33%
- PitchShiftDelay - a continuous 8%
But does measuring CPUs on Silicon means anything ? It was already a bit complicated before but now with high performance and high efficiency cores...? In any case, your plugins work very well and that is what matters most !!
@opasquetdotfr Regarding PitchShiftDelay, CPU usage on my machine depends a lot on Pitch and Delay Time values, try setting Pitch at more than 100 and Delay Time close to 10 s.
@ryukau It seems that I missed something during my testing, but ParallelComb does not change sound. Controls that are working are Dry level, and OverSampling toggle increases CPU usage. All other controls have no effect when changed. Also Wet level has no effect on output. This behaviour is happening on both Mac ARM and Win (i7-3820) builds.
@opasquetdotfr Hi, and thanks for testing! Also nice to see you again.
The reason I asked CPU load is that fully SIMD optimized code could run 4 or 8 times faster than the non-SIMD code in ideal situation. The plugins currently available on M1 mac was solely relying on compiler options (-mavx and so on) for using SIMD. I wasn't sure how much difference it makes without those options.
@nekotaro6 Thanks again for the bug report.
I reproduced the bug on REAPER v6.58/win64. Fixed version of ParallelComb is attached on this message. Please let me know if it works on your environment.
Fixed version of ParallelComb now works correctly on M1 Mac and Win64 (Tested in Ableton Live 11.1.5 and REAPER v6.58).
I have a question regarding MiniCliffEQ. On M1 Mac MiniCliffEQ has low average CPU load (5%) but it constantly causes high CPU spikes, visible on real-time CPU meter in Ableton Live 11.1.5. With sample rate 44100 and buffer size 128 spikes exceed 100%, which causes short audio crackles (CPU core overload). With buffer size 512 average load is 10% and spikes are at 50% CPU load (No audio crackles). Is this intended behaviour of MiniCliffEQ?
The same result appears in REAPER v6.58 if Anticipative FX processing turned OFF in REAPER Preferences. REAPER's real-time CPU meter does not show spikes, but audio crackles still occur. If Anticipative FX processing turned ON, there are no audio crackles.
I cannot compare the results on Win64, because MiniCliffEQ crashes Live and fails plugin scanning in REAPER there. Perhaps this caused by old CPU (i7-3820), since CubicPadSynth also crashes Live and fails plugin scanning in REAPER.
Thanks for confirmation. I'll package them into next release.
I opened issue #18 regarding on MiniCliffEQ. In summary, the CPU spikes are part of intended behavior, but can be improved.
@nekotaro6 About the crash on windows, I suspect that FFTW3 is branching into unavailable SIMD instruction set. Below is a download link of MiniCliffEQ and CubicPadSynth using FFTW3 without SIMD flags. If you have time, let me know if they work on your windows environment.
Indeed, now MiniCliffEQ and CubicPadSynth are working on my windows machine (Live + REAPER). Thank you.
Thank you too. I'll update them for next release.
Hi! Just a tiny comment - we have loads of simd in surge and compile on arm using https://github.com/simd-everywhere/simde which really just required us to divert a header in one spot. Works great! If you’re interested I can share our cmake tricks and what not. (I saw your synth in a music tech roundup and hopped over then saw this thread so figured it might help!)
Hi, @baconpaul.
I use VCL for SIMD abstraction, and my plugins are relying on math functions provided by VCL (example). Does simd-everywhere provide math functions like pow? exp2 is also okay for the linked example case.
I also recently learned about valarray, and considering to replace VCL's Vec16f with it. If you or someone are willing to test the valarray version on ARM mac, let me know about that. I can start work on it.
Just in case, following plugins are the current subject. Others are already SIMD free:
- CubicPadSynth
- EnvelopedSine
- EsPhaser
- IterativeSinCluster
Simde basically subs our raw intrinsics with their neon equivalent so _mm_sub_ps gets replaced with the neon vadd intrinsic. I don’t know if it would allow you to compile a higher level library to arm and have not used vcl; in surge we have our own sse approximations of exp sin tan tanh etc mostly borrowed from juce fast math and vectorized. So my comment may not be helpful! Apols!
In that case, I'll probably use valarray. Thanks for the tip anyway.
I got universal binary of following plugins from add_sse2neon branch. They are not tested. If anyone is interested in, please let me know if they work on ARM mac.
- CubicPadSynth
- EnvelopedSine
- EsPhaser
- IterativeSinCluster
Download link: vst_macOS.zip
Hello, i have tested new binaries on M1 Mac. Working fine in Reaper (both native and Rosetta).
@nekotaro6 Thanks for confirmation!
These version will not likely land on master branch, but they can work as a makeshift replacement. Or, I'll fallback to them when SIMD rewrite is not going well.
aarch64 code paths are added to following plugins, and now available as Universal 2 binary.
- CubicPadSynth
- EnvelopedSine
- EsPhaser
- IterativeSinCluster
I'll close this issue as resolved. If something is not working, feel free to add comments, or open another issue.