ashafq

I write about signal processing.

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

GitHub: https://github.com/Colahall/tiny85fancontrol/tree/main/schem... Codeberg: https://codeberg.org/Colahall/tiny85fancontrol/src/branch/ma...

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

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.

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.

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!

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.