So, I would suggest a better question is: where can I find an introduction to this stuff that is better aligned with my current understanding and knowledge. To that end, here's a great intro book: https://www.dspguide.com/
I read that cover to cover when I was 17 and I would not have been described as particularly mathematically gifted.
The things you can hear scale pretty well all the way down to DC, and all the way up to daylight (or beyond, I suppose).
After spending a few (or dozens, or hundreds) of hours tinkering with audio-range frequencies for fun, then maybe you'll have a real place with which to associate the maths that are involved in electronics and programming, and having that place might make that math (and whatever is needed to accomplish it) feel lot more worthwhile to actually-learn.
I agree. Start with small hobby projects using what you already know.
They should be things where you get immediate feedback, like graphics or sound. That makes them very fun to work and iterate on. It's addicting when you see/hear the output, make a change in a few seconds, and immediately see/hear the results of your change. That's the stuff that keeps you up all night at the computer.
You'll start hitting barriers where you need more math to get better results. Then you'll be much more motivated to start learning, and it will be easier to retain the knowledge when you actually use it in practice.
For instance, use Python to output audio samples. Start with simple sine wave tones, colored noise, and work your way up to implementing simple FIR and IIR filters to modify input audio like voice and music. Use Audacity to see the change between input and output as a spectrogram.
If you're into music, use an existing Python library to read MIDI files with songs you like. Generate audio output files for those songs. First with just sine waves for the notes, then you can start emulating digital and analog synths. Write code that takes sampled audio files and emulate different guitar sound effect pedals or tube amplifiers.
Don't look too much at the Greek letters, look at the tables and code instead. A DCT is just a bunch of multiplications, additions and a lookup table. The approach to derive the Walsh-Hadamard transform is actually very computer sciencey. It is made using a recursive algorithm, it then takes advantage of the fact that a+b==b+a to reorder the rows. There is even a trick that uses a bitwise AND.
As a programmer I find it much easier to start from here: tables, loops, and simple operations like multiplication and addition. And when I finally understand how a computer does the thing, maybe go back to the maths to see if I can get more insight.
In the end, the only appropriate answer is "get good at maths". The question is how to achieve that. And if you have a programmer mindset like I do (and I guess like many people here) and struggle with maths, I recommend trying the bottom up approach. Write the code, have it actually show visuals and play sounds, play with the parameters and see what changes and what doesn't change.
The other part is overcoming the language barrier, I am still struggling with that. Mathematicians use barbaric name like eigenvectors for "stuff that won't change", they call "integration" an addition in a loop and write it with a weird sigma thing, or a weird "S" thing when there are a lot of iterations over very small numbers. But in the end, it is not that different from reading Perl :)