I think this is a message that a majority of you have probably been dying to see for a while now.
With the help of @baconpaul and @pgatt, I have upgraded my plugins, Valley, to 2.4.0 beta. This introduces the much needed support for Apple Silicon / ARM64 instruction sets, plus other things (details to follow, try diffing the code with git if you want).
In order for me to get this onto the library as swiftly as possible, I’m calling on devs with access to Windows, Linux, and Apple Silicon Macs to test the hell out of this update. As of right now, I simply don’t have enough time to get this done efficiently, so your help will be much appreciated.
I’m getting a make error when trying to build the v2.0 branch on Mac Arm64 (no problem on Windows though):
marcboule@Marcs-MacBook-Air ValleyRackFree % make
c++ -O3 -Isrc -std=c++11 -stdlib=libc++ -fPIC -I../../include -I../../dep/include -MMD -MP -g -O3 -funsafe-math-optimizations -fno-omit-frame-pointer -Wall -Wextra -Wno-unused-parameter -DARCH_ARM64 -march=armv8-a+fp+simd -DARCH_MAC -mmacosx-version-min=10.9 -c -o build/src/Dexter/Dexter.cpp.o src/Dexter/Dexter.cpp
In file included from src/Dexter/Dexter.cpp:8:
In file included from src/Dexter/Dexter.hpp:31:
In file included from src/Dexter/DexterCore.hpp:28:
In file included from src/Dexter/../dsp/generators/QuadOsc.hpp:18:
In file included from src/Dexter/../dsp/generators/../shaping/Shaper.hpp:11:
/Library/Developer/CommandLineTools/usr/lib/clang/14.0.3/include/pmmintrin.h:14:2: error: "This header is only meant to be used on x86 and x64 architecture"
#error "This header is only meant to be used on x86 and x64 architecture"
^
Hmm… Please correct me if I’m wrong, but glancing at recent commits in the source code, it appears to me that the four filter cutoffs changed (during your recent refactoring) from 0–10V to ±5V.
Edit: That is, Rack reads and writes the ‘internal’ values of parameters from/to JSON, not the ‘display’ values (which I believe have not changed during the refactoring). (FWIW, the initial value set in Plateau’s header file is still 10.0f, not the 5.0f that I believe would be consistent with the new parameter value range of ±5. [Oops, I was confusing the local variable, which is still correctly 0–10, with the knob’s parameter value, which is now ±5V. But the ±5V parameter configuration does still look to me to be a breaking change.])
Found the issue, the reason I changed the parameter offset was so I could display the cutoff frequency of those parameters. I changed the range back 0 to 10 and recalculated the v/Oct to freq scaling factor so it would display the correct cutoff frequency.
I kinda suspected as much. The change itself to the new value range looked to make perfect sense, but it was only after your initial response above that I realised this consequence hadn’t been intended.
Thanks for fixing this so quickly… And many thanks, of course, for providing these modules in the first place!
If I start Rack with no audio device configured “(No device)” I can consistently crash Rack if I select an output device while having a low sampling rate set in the engine. If, instead, I select an output device while the engine sample rate is greater (say, 44.1 kHz) then the Rack doesn’t crash.
Or try this: select audio device & a decent sampling rate. Load Valley Plateau. Lower the engine sampling rate & exit Rack. On restart, Rack crashes on every startup unless you choose to clear the patch.
Bingo! That may be what is tripping the assertion: a samplerate of 0. The assertion assumes that the samplerate will be more than 0, but I must not have taken some default behaviour of Rack into account.
Yeah, the lower sample rate issue might be that when you go down to a lower samplerate, the assertion isn’t using that new samplerate, so the check fails. Cool, I think I can start to pin down the issue. Thanks for informing me about this
