search

ryukau / VSTPlugins

Uhhyou Plugins VST 3 repository.
https://ryukau.github.io/VSTPlugins/
GNU General Public License v3.0
327 stars 12 forks source link

MacOS build #17

Closed kmturley closed 1 year ago

kmturley commented 2 years ago

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?

ryukau commented 2 years ago

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

kmturley commented 2 years ago

I use a Mac, let me know if you want me to test anything out?

ryukau commented 2 years ago

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.

vst_macOS.zip

Also if you have ARM mac, I'd like to know CPU load of following plugins.

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?

nekotaro6 commented 2 years ago

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%

ryukau commented 2 years ago

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:

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.

opasquetdotfr commented 2 years ago

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

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

CPU usage (1 core) with sample rate 44100 and buffer size 128 (which is super short) Max 8.3.1 (native)

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 !!

nekotaro6 commented 2 years ago

@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.

ryukau commented 2 years ago

@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.

ParallelComb_0.2.1.zip

nekotaro6 commented 2 years ago

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.

ryukau commented 2 years ago

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.

ryukau commented 2 years ago

@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.

CPS_MCEQ_win64_fftw3_change_2022-06-24.zip

nekotaro6 commented 2 years ago

Indeed, now MiniCliffEQ and CubicPadSynth are working on my windows machine (Live + REAPER). Thank you.

ryukau commented 2 years ago

Thank you too. I'll update them for next release.

baconpaul commented 2 years ago

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

ryukau commented 2 years ago

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:

baconpaul commented 2 years ago

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!

ryukau commented 2 years ago

In that case, I'll probably use valarray. Thanks for the tip anyway. 👍

ryukau commented 1 year ago

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.

Download link: vst_macOS.zip

nekotaro6 commented 1 year ago

Hello, i have tested new binaries on M1 Mac. Working fine in Reaper (both native and Rosetta).

ryukau commented 1 year ago

@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.

ryukau commented 1 year ago

aarch64 code paths are added to following plugins, and now available as Universal 2 binary.

I'll close this issue as resolved. If something is not working, feel free to add comments, or open another issue.