HN user

ashafq

30 karma
Posts10
Comments18
View on HN

I’m building SPARK (Signal Processing Algorithms, Routines, and Kernels), an open-source library of modular, efficient DSP components for low-power embedded audio systems.

The goal is to make it straightforward to design and deploy small, composable audio graphs that fit on MCUs and similar hardware. The project is in its infancy, so there’s plenty of room for experimentation and contributions.

https://github.com/Colahall/SPARK

I did try the internal temperature sensor, but it didn't measure the ambient temperature. I have read that if you set the ATtiny85 to sleep mode for some time, it will converge to ambient temperature, but it would take too long to validate, and I didn't want to go down another rabbit hole.

USB Bootloader is interesting, but I already had a few ISP loaders. You can make an ISP loader with Arduino as well. [1]

[1] https://docs.arduino.cc/built-in-examples/arduino-isp/Arduin...

If you've ever wrestled with fixed-point math, scaling, and rounding, this blog post is for you!

I go deeper into binary arithmetic, division tricks, rounding, and what it really takes to build fixed-point systems that actually works.

As always, I appreciate all of your feedbacks and corrections.

If I recall correctly, SVFs typically compute lowpass, highpass, and bandpass outputs simultaneously, which are then combined to create peaking or shelving filters. In contrast, a traditional biquad filter requires only five multiply-accumulate instructions. Computationally, SVFs are generally 3 to 5 times more expensive than biquad filters.

When designing this plugin, my primary focus was optimizing steady-state operation. While there are many plugins tailored for handling modulation, this plugin is designed to reject high-frequency modulation, prioritizing efficiency for gradual state changes. This tradeoff allows it to excel in its intended use case without the added complexity or overhead of robust modulation handling.

Feel free to add a feature request in the Github project page. Thanks again for your feedback.

Thank you for your feedback. You’re absolutely right that TDF-2 can exhibit artifacts in the presence of modulation or automation. In this implementation, I’ve addressed this by crossfading between the old and new coefficient sets. I’m aware of the SVF topology and its advantages, especially in low-precision applications. However, I wanted to experiment with biquads due to their computational efficiency when filters remain steady.

I hadn’t fully realized the extent to which EQ cramping is a concern in the audio community, so I’ll definitely dive deeper into mitigation techniques to address it effectively.

Regarding your point about limiting to five bands, I completely agree: there’s no technical reason to impose this restriction, especially given the abundant memory available on modern desktop systems. I’ll explore a more dynamic architecture to allow for arbitrary numbers of bands.

Thanks again for sharing your insights. They’ve given me a lot to think about as I work on improving this project!

Thank you for taking the time to share such detailed feedback. It’s incredibly valuable! Let me address your points one by one:

1. Logarithmic plot and spectrum analyzer: This feature is definitely on my roadmap. I agree that having these visual cues is essential for live tuning and precise adjustments.

2. UI grouping: You’re absolutely right about grouping parameters by EQ band rather than by type of control. Your suggested layout makes a lot of sense, and I’ll admit I took a shortcut by organizing the UI the way it is now. I’ll reference this thread in the corresponding GitHub issue to ensure it’s tracked for improvement.

3. High-pass and low-pass filters: I completely agree these are essential additions. I might explore adding them as a separate mode for the EQ. As for slopes, implementation could be a bit trickier since biquads inherently support only 6 and 12 dB/Oct. I’ll add this as a feature request on GitHub so it can be properly tracked and discussed.

4. Mid/Side mode: This is an intriguing suggestion and could offer a lot of creative possibilities. While it’s a bit more complex to implement, I’ll look into how it could fit into the current architecture.

5. EQ cramping prevention: The current design inherently avoids EQ cramping due to the use of the TDF2 transposed structure for biquads. However, I’ll review other topologies to see if there’s room for further optimization.

Thanks again for such thoughtful feedback. It’s input like this that helps me refine and improve my plugins. Also, feel free to jot down any feature requests in Github.