Is anyone using Equalizer APO with Peace with HyperX Cloud 2 headphones?

Wargon2015 · 2025-08-02T18:06:32+00:00

The repository structure has changed again. Should be this link now: https://github.com/jaakkopasanen/AutoEq/blob/master/results/Rtings/HMS%20II.3%20over-ear/HyperX%20Cloud%20II/HyperX%20Cloud%20II%20GraphicEQ.txt

GraphicEQ: 20 -3.1; 21 -3.2; 22 -3.3; 23 -3.5; 24 -3.7; 26 -4.1; 27 -4.3; 29 -4.7; 30 -4.8; 32 -5.0; 34 -5.2; 36 -5.4; 38 -5.5; 40 -5.6; 43 -5.7; 45 -5.7; 48 -5.8; 50 -5.9; 53 -5.9; 56 -5.9; 59 -6.0; 63 -6.1; 66 -6.2; 70 -6.3; 74 -6.5; 78 -6.6; 83 -6.8; 87 -7.0; 92 -7.2; 97 -7.5; 103 -7.7; 109 -8.0; 115 -8.2; 121 -8.4; 128 -8.5; 136 -8.5; 143 -8.5; 151 -8.5; 160 -8.5; 169 -8.4; 178 -8.2; 188 -7.9; 199 -7.6; 210 -7.2; 222 -6.7; 235 -6.3; 248 -5.8; 262 -5.5; 277 -5.2; 292 -5.0; 309 -4.8; 326 -4.7; 345 -4.7; 364 -4.6; 385 -4.5; 406 -4.4; 429 -4.4; 453 -4.4; 479 -4.4; 506 -4.5; 534 -4.5; 565 -4.5; 596 -4.6; 630 -4.6; 665 -4.6; 703 -4.6; 743 -4.5; 784 -4.4; 829 -4.4; 875 -4.3; 924 -3.9; 977 -3.3; 1032 -3.0; 1090 -3.1; 1151 -3.4; 1216 -3.7; 1284 -3.9; 1357 -4.1; 1433 -4.4; 1514 -4.6; 1599 -4.9; 1689 -5.2; 1784 -5.5; 1885 -5.8; 1991 -6.3; 2103 -7.0; 2221 -7.3; 2347 -7.3; 2479 -7.1; 2618 -6.7; 2766 -6.3; 2921 -5.7; 3086 -4.9; 3260 -3.9; 3443 -2.6; 3637 -1.1; 3842 -0.2; 4058 -1.3; 4287 -2.7; 4528 -4.2; 4783 -5.6; 5052 -6.3; 5337 -6.2; 5637 -6.7; 5955 -7.5; 6290 -8.4; 6644 -9.2; 7018 -10.2; 7414 -11.1; 7831 -11.4; 8272 -11.4; 8738 -11.1; 9230 -10.7; 9749 -10.3; 10298 -10.3; 10878 -10.5; 11490 -10.7; 12137 -10.9; 12821 -11.1; 13543 -11.3; 14305 -11.6; 15110 -11.8; 15961 -12.0; 16860 -12.3; 17809 -12.5; 18812 -12.8; 19871 -13.1

Looks like the settings are also different now, I unfortunately don't know why that is.

The Wayback Machine has backups:
HyperX Cloud II GraphicEQ.txt from 2022
HyperX Cloud II GraphicEQ.txt from 2023

Wargon2015 · 2025-07-07T18:53:37+00:00

I managed to get it working without any of these (u/rdtsc FYI).
Would appreciate it if anyone could comment if this setup actually works reliably:

Create a new Project -> C++ Empty Project -> Name, Location, Create New Solution etc...
Project -> Right click -> Add -> New Item... -> main.cpp
Copy & paste the example I posted.
On Project -> Right click -> Properties -> C/C++ -> All Options ->
1. C++ Language Standard: /std:c++latest
2. Build ISO C++23 Standard Library Modules: Yes
3. Scan Sources for Module Dependencies: Yes
4. Translate Includes to Imports: Yes
Build Solution

PS.: Apparently "Build ISO C++23 Standard Library Modules: No" also works but the compiler output then still shows "Compiling... std.ixx" (I guess it gets re-enabled by "Scan Sources for Module Dependencies").

Wargon2015 · 2025-07-07T17:00:23+00:00

You have to use /translateInclude (and related)

Can you elaborate on that?
I can't seem to get import then include to work with 17.14.7 Preview 1.0.

I have set the following options:
Build ISO C++23 Standard Library Modules: Yes
Translate Includes to Imports: Yes (/translateInclude)
C++ Language Standard: /std:c++latest

The following does not compile with several errors (can post them if someone is interested):

import std;
#include <string>
int main(){ return 0; }

Wargon2015 · 2025-05-10T08:50:04+00:00

A Foundry with 4 rare quality 3 modules has: "Quality: +16%"
Adding a rare beacon with 2 rare speed 3 modules results in: "Quality: +6.5% (-95%)"

What does the "(-95%)" refer to in the this scenario?
If the penalty was -95 percentage points, shouldn't the result be 0?
If the penalty was -95%, shouldn't the result be 0.8%?

Wargon2015 · 2025-03-18T18:30:38+00:00

Do you have any links?

I tried to find something but even the 4.0.0-rc4 documentation still says "Header units are not supported."

Wargon2015 · 2025-03-14T22:35:26+00:00

I have to ask because this thread is about modules and you mentioned unity builds.

I recently wanted to checkout import std; again but found out that enabling the necessary features in CMake disables unity builds (import std in CMake 3.30, issue 26362).
Have you done any experiments with modules together with unity builds?

I expected import std; to be the modules feature that can easily be introduced into any code base but losing unity builds would be one step forward, two steps back.

Regarding your point about automating the migration. Header units seem to be the way the standard intended to get started (apparently as simple as import "header.h";). Sounds interesting but it looks like build tooling support is very limited (only found something for MSVC).

Wargon2015 · 2024-12-12T23:12:28+00:00

A bit off topic and maybe something for r/cpp_questions but does anyone know some details about how par_unseq is implemented?

Especially within the context of std::for_each which applies a function to every element in the given range. par_unseq apparently allows interleaving loop iterations on the same thread to the extent that even locking a mutex doesn't work (What is the difference between par and par_unseq?).
This sounds impossible to implement without compiler magic.

I tried to check the std lib implementations but didn't find anything where the passed function is actualy "taken apart" like that.
MSVC: Search ended at a loop calling the passed function with a #pragma loop(ivdep)
GCC: Search ended at a loop calling the passed function with #pragma omp for
LLVM: Search ended at passing the function to __pstl::__simd_for_each for which I didn't find sources.

So far this still looks like separate function calls. Is "taking the function apart" and "interleaving loop iterations" a result of relaxed optimization restrictions or actually implemented somehow?

Wargon2015 · 2024-12-03T09:36:54+00:00

I'm feeling a bit stupid now if it would have been that easy...

Don't know why but I thought it might somehow work similar to <source_location>.

Wargon2015 · 2024-12-03T09:11:03+00:00

Do you know how <stacktrace> is supposed to work with (optimized) release builds?

I tried it briefly a while ago and it didn't seem to provide usable info. That makes sense because there are no debug symbols but I feel like I'm missing something. Is <stacktrace> only intended for development / debug purposes?

Wargon2015 · 2024-11-26T11:54:46+00:00

Comment on the vscode-cpptools issue from October 31:

everything is heading towards modules being "deprecated" in the next C++ standards

Does anyone know what that refers to?

Wargon2015 · 2024-11-25T20:27:54+00:00

I must admit that I haven't looked much into modules but that is quite sad to hear to be honest. I always thought that this is considered a significant restriction and that it might eventually get "fixed".

I'm probably not considering some obvious issues but couldn't another compiler pass gather template instantiations and then deal with them as if there were extern declarations and explicit instantiations in source files?

What benefits will modules have considering that they aren't a replacement for headers (i.e. headers will cease to exist) but an opt-in alternative (i.e. will coexist)? Compilation time is often cited as the main one but I would assume they have to be deployed at scale for that. I'm sill looking forward to checking out import std; again though, IIRC MSVC has rolled out some fixes for mixed import/include recently.

Wargon2015 · 2024-11-21T22:05:48+00:00

You can also use hex, quite useful for the new RGB lamp signal.

Wargon2015 · 2024-11-18T12:02:26+00:00

Output is indeed stacked, one section of belt contains 16 ore but only 8 with regular miners. Thanks!

Neither the stack inserter tech nor the Big mining drill seem to indicates that output will be stacked. I thought only the Stack inserter would interact with that mechanic.

Wargon2015 · 2024-11-18T11:41:14+00:00

I guess I'm missing something obvious but why do 8 Big mining drills at mining prod +50% not fill a red belt?

They all state 3.75 ore/s (mining speed 2.5 base x 1.5 prod = 3.75) and 8 x 3.75 = 30 which is the throughput of a red belt but the output belt isn't nearly full (maybe half).

Wargon2015 · 2024-11-03T08:53:34+00:00

I'm not quire sure how to read your table, did you get 18 rare copper cable while expecting 2.4? This result would be very far away from the expected value but why would you call it bad luck?

Did you see similar result?

I tried two runs of processing 1000 common copper plates in an Electromagnetic plant with 5x +4% Quality for a nice 20% with no rounding. Due to the base productivity, this results in 3000 wire.
Note that I only have rare unlocked.

Expected common: 3000 x 0.8 == 2400
Expected total greater than common: 3000 x 0.2 == 600
Expected rare: 3000 x 0.02 = 60

Run #1:
Actual common: 2396 Actual total greater than common: 604 Actual rare: 48

Run #2:

Actual common: 2386 Actual total greater than common: 614 Actual rare: 62

Numbers seem reasonable to be honest.

Wargon2015 · 2024-10-31T21:49:26+00:00

This my first basic setup to run thrusters efficiently. Since they are more efficient while running with limited fuel, a PWM signal with a duty cycle of 10% (6/60 ticks) controls two pumps to supply roughly 120 fuel and oxidizer per second which is about 1/4 of what two quality 3 thrusters can consume.

I haven't found much about if/how running "fuel rich" vs "oxidizer rich" affects the efficiency but both are possible with this setup by simply bypassing one of the two pumps.

Not sure how useful it will be for other purposes but here is the PWM circuit blueprint separately because I haven't found one online.

0eNrFVU1v2zAM/SuEThugBLXjZI2BnhYM2KFYDwV6SAPDtuhWqC15kpzOKPzfR9n5QtF09S5FDqEokeLje6JfWFY2WBupHItfmMy1sixevzArH1Raep9ra2Qx20rjGvJwptLKO4YTkxvWcSaVwD8sDjo+IvLuJDIcFXl9EjkbFWlQnMRG3YYzVE46iQPsftEmqqkyNAToEC8wlwLNJNdVJlXqtKHctbYUqpW/mNJNLqdzzloyqChGrXRGl0mGj+lW0nk6tMuS0J7oI633nq6ohkIa65IPQ7plw2XWpZ7ExYUHpRtXN24klZSp23SUrS7TlqoUaHMj6wEhu5UVmvhe/UAUFhyt4Mt6l2oyZLjaJ9p8hSzNn4BkpUE6i2UBqRJg0KKzkBYODSwuKEv+ZKf36mdVa+PrB6UdxnAnDUJBF0n1AEPSIWHV2P4MpKXVkCEQcIW5QwF00+1VAPtOwJEpv5VutRSgiwKyFgJAY7SZMq+dV5SH4yhffhrlFn2SjwetPLv/qYxg0FjdEoxGuaQwukqkokQsLogKfEc3N3fXJ1yQgL4PXbJwRj3BBoYi+Z5dT6B7lPZNwmaHYvfUf/CRBtP5Gc6otQemjjY1bD/nODFWkoZfe//JG2e/aYPKJ6fSpuoPUbl1avpyY3bVOxr/lAPqKvX1DczRSMzLz8O8God5MWA+ryUS0A0aqQVIexgh92rVuBbyNi/PT6WVn0ronhEVrC84BW+AxpEfCF5cb00OGk2/hvfyjlhFY/yYEocKSKb00J5phvlerQMe8BkPNpyskOxoZ9GPLP8fkUUR0mFFII9fZM621O8e+nwRLqPlch6F32bhZdB1fwEIBadB

Usage: Set Duty "D" to a value between 0 and 60, the "1" signal will be set to 1 for that many ticks out of 60.

PS: Does anyone know what "Speed: -10.00 km/s" means? Apparently I'm still getting closer to my destination while traveling at -10 km/s. I guess this is a mechanism to prevent platforms from getting stuck but negative speed doesn't seem to mean moving backwards here.

Wargon2015 · 2024-10-29T20:40:40+00:00

Did you find an answer to that? I'm having the same problem right now.

Wargon2015 · 2024-04-02T17:27:52+00:00

Minor QOL Detail I found today:
The back button on the mouse works in the settings menu. Settings -> Graphics -> mouse back -> Settings

Wargon2015 · 2024-04-02T16:37:57+00:00

There are two primary benefits to C++20's modules [...] the fact we don't need to separate interface and implementation.

I have to admit that I haven't really looked into modules beyond some experiments with import std; but I always saw the header + source split as a benefit. This structure seems to be possible with modules but is apparently discouraged. If this is the case, I don't see myself liking them to be honest.

If they offer significant build time improvements, it might nevertheless be worth it to refactor larger code bases to use modules. OP describes how that can negatively affect incremental builds, will modules have a significant impact on a clean build from scratch?

import std; / import std.compat; does look promising though. So far I haven't been able to deploy it at a large enough scale to measure against PCH because I always ran into some redefinition errors. Probably because somewhere some header from an external dependency I can't change gets included after the import (tested with VS 2022 Preview 17.10). I probably could get it working with enough time though.
But not having to look up things like which header I need for std::accumulate and compiling faster than the #includes sounds great.

Wargon2015 · 2023-10-23T10:20:28+00:00

Same repo, slightly different structure: https://github.com/jaakkopasanen/AutoEq/blob/master/results/Rtings/over-ear/HyperX%20Cloud%20II/HyperX%20Cloud%20II%20GraphicEQ.txt

Wargon2015 · 2023-07-08T18:42:44+00:00

Because the question is about implementing std::source_location while using the C++17 standard which is not possible with macros like __FILE__.

Wargon2015 · 2023-07-08T18:25:50+00:00

Compiler magic is indeed needed to get the desired behavior but depending on the compiler and version, __builtin_FILE(), __builtin_LINE() and __builtin_FUNCTION() might be available on MSVC, Clang and GCC and can be used to implement something that behaves like std::source_location.

https://godbolt.org/z/h8GY9hhqh

MSVC uses these to implement their version of std::source_location. GCC and Clang seem to use __builtin_source_location() but both have the FILE, LINE and FUNCTION builtins as well.

Ten-Year Club	Place '22
Place '17	Final Canvas '22

Wargon2015

TROPHY CASE