Good point -- we will check that next time we're in.

Maybe? It's not obvious to me how to adapt it. In general attempts I've seen to use Walsh functions have been kind of tricky, since the control of the coefficients winds up being really counterintuitive. Your first term is a square wave with lots of harmonics, and then you need to add terms to tame it.

I suppose that’s true if you are using C as something of a portable assembler so the C itself is a target of compilation from some other language; you need something that translates directly to underlying assembly jump instructions. But I don’t think I’ve ever written a single goto in C or ever felt the urge to write one. I’d imagine gotos are not looked on fondly in most code reviews.

RME is amazing. Fireface 800 is twenty years old, and RME is still keeping the drivers for it up to date! I'm using a Mac M1 with the latest OS and the Fireface is rock solid.

@@Lantertronics They have zero cpu load drivers. check their website who is using RME around the world, pretty stunning list even in places you wouldn't expect. It's publicly traded company. i often argued with friend to get RME and i was a RME fanboy.

You are welcome!

Heh! Check out the intro to my lecture on State Variable Filters: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-jAokGV71MEw.html

​@@LantertronicsLol! 🙈 I should have known! ...I wouldn't mind, but I had watched that video before! 😂👏👏👏

I'm hoping to get a student who wants to work on it this year. :)

Thank you for your kind words!

Oh, yeah, technically speaking some of it is will always be unavoidable in the formulas I'm using, just like in regular Yamaha-style FM synthesis. You hope that the partials decay fast enough that the aliasing isn't objectionable. My suspicion here is there's also some numerical weirdness going on with the division that's making these effects sound more objectionable here... but I don't really know for sure.

I just subscribed to your channel -- great music!

@@Lantertronics thank you so much! I’m so glad you liked the music!

Thank you for your kind words!

For large-scale programming projects, Python is a better choice; MATLAB evolved from an interactive wrapper for FORTRAN array routines and was never really properly designed as a language. But for things like this, I find MATLAB to be a much better fit (while also being accessible without paying silly $$$ because of Octave.) It has everything I want "out of the box" without having to think about installing and importing this library or that library, and more importantly, its syntax is tightly tied to the problem domain it targets. I could write this code much faster in MATLAB than in Python, and I think the resulting MATLAB is easier to read the the equivalent Python. To a certain extent, of course, this is a skill issue; the ratio of hours I've spent in MATLAB vs. the hours I've spent in Python approaches infinity. But being able to write a = [2 3 4; 5 6 7] is much more convenient than having to write np.array([[2, 3, 4], [5, 6,7]]), and I prefer writing A * B * C for matrix multiplication over something like np.matmul(np.matmul(A,B)),C) or even A @ B @ C. But then I seem to recall * is matrix multiplication for NumPy *matrices*, which are different than NumPy *arrays*, or something. So I can think about all of this, or I could just write MATLAB code and finish the video. ;) We've occasionally looked at switching our ECE2026: Introduction for Signal Processing course at Georgia Tech from MATLAB to Python and have always concluded that it's just much cleaner to express things in MATLAB. There's a new language called Julia that looks very interesting to me; it's kind of like what MATLAB could have been if it was thought through properly as a language from the get-go.

Mathworks has all sorts of tools for going from MATLAB to FPGA, but really for real-time synthesis would want to code it very different than I've coded it (I've coded it all with bulk vector operations). You'd probably be better off coding for the Xilinx directly, or writing C++ directly for something like an STM32.

I also think that if you do the double sided sideband summation using the complex version, not everything will cancel. I guess the same would hold if you did the summation using cosine terms instead, but I think the complex version is easier to deal with. Another nice thing about the complex version is that the imaginary part is the Hilbert transform of the real part (or possibly vice versa). I made a complex feedback comb filter once (the samples in the delay line were complex, as was the feedback coefficient). At least when fed with the output of the complex version of the summation formula, I could get the resonance peaks to move around along the frequency axis by changing the phase of the feedback coefficient.

Toivo, can you share your derivation and perhaps some tips on using your formula?

@@bobvines00 Sure: Ok, we're using the sum S = sum[k=0 to N] exp(z + k*w) = exp(z) * sum[k=0 to N] exp(w)^k First note that if z = ib, then exp(z) = exp(ib) = cos(b) + i*sin(b) so you can use the real part to get a cosine or the imaginary part to get a sine. Now, let w = c + id, then I can write the sum as S = sum[k=0 to N] exp(i(b + k*d)) * exp(c)^k Let's say that b = 2pi*ft, d = g(2pi*t + p), then S = sum[k=0 to N] exp(i(2pi*ft + k*g(2pi*t + p))) * exp(c)^k = sum[k=0 to N] exp(i(2pi*(f+kg)*t + kp)) * exp(c)^k so we get a sum of cosines/sines (depending on if we take the real or imaginary part) with frequency f+k*g, with exponentially decreasing amplitude if c < 0. The sum starts at frequency f and ends at f + N*g. The variable p can be used to add a phase offset from one sine to the next. I hope that explains the basic usage. Derivation: We exploit that it's a geometric sum. By multiplying by 1 - exp(w), the first term in the sum times -exp(w) cancels with the second term times 1, etc, which gives (1 - exp(w))*S = exp(z) * (1 - exp(w)^(N+1)) ==> S = exp(z) * (1 - exp(w)^(N+1)) / (1 - exp(w)) You can see that if N=0, you get back S = exp(z), as expected. If N goes to infinity and real(w) < 0, exp(w)^(N+1) goes to zero. But the case with finite N is really useful, you can choose N so that f + N*g is below the Nyquist frequency to avoid aliasing, but if f + (N+1)*g is above then you're not missing out on any audible frequencies. Hope that helps.