Valley 2.4.1 support thread

It is not on the library yet. Read further down

Hi everyone,

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.

Thank you in advance.

Dale, ValleyAudio


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"

Just comment out the *intrin.h includes from the header files (there are a few) and it builds… At least it did for me

1 Like

They were taken care of in the latest pull request, my commit before that one had a stray Intel header file


any chance to get a win binary to test it?

yep, builds clean on arm64 now.


Submitted for review by the library admin, hopefully the update will be available over the weekend :slight_smile:


Before update (L) After Update(R)

Did something change in the Low/High filter settings ?

Better example I think the Low/High settings are not recalled correctly between versions

Win10 Rack Free 2.4.1.

Probably a Rack issue, the knob behaviour (including saving a recalling) is default.

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.])

1 Like


Here the knob values (1,2,3,4) BL BR TL TR turn into

6,7,8,9 BL BR TL TR

This is not a 1:1 translation.(recalling)


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.

1 Like

Thank you Dale for looking into it :hugs:

1 Like

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!

2 Likes - This assertion seems to be getting the best of me:

Rack: src/dsp/filters/OnePoleFilters.cpp:36: void OnePoleLPFilter::setCutoffFreq(double): Assertion `cutoffFreq <= _maxCutoffFreq’ failed.

Abort (core dumped)

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.

Verified on Linux & Mac.

I think he’s working on it

1 Like

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.

1 Like

Zero or any of the lower sampling rates. Try 24 kHz. Repo:

  • Empty patch
  • Set sampling rate to 44.1k
  • Load module
  • Set sampling rate to 24k
  • Close Rack

Can’t reopen unless you clear the patch.

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

1 Like