I own 2 boss HM-2's, an old made in Japan, and a Waza craft, both sound great thru my amp sims, but every plugin I tried was dissappointing, so I made an effort to improve that. Since I build 3 circuit models of Rolands TR-606, TR-808 and TR-909, the switch to guitar pedals wasn't that difficult. and the results are very rewarding, now I finally have a real alternative for the real ones.

Both have dry blend, gate, input and output meters. hm-2 model has a supply voltage simulation. the RAT has the hm2 added to it, because why not.

Happy to answer anything about how they're built. nothing is fitted, nothing is eq-matches, the sound is just a result of modelling the circuit.

Try out for yourself if you are curious about the results. happy to answer questions about the techniques used .

https://beatforge.nl/#pedals

What would be optimum storage for fftw3 outputs? I want to try random forest classifier for Oracle or pgsql over spectrum data but not sure how to store spectrum. What are common patterns? Input stream is 4 to 8 ch tone sampled at 48kHz.

Hello!

I am interested in reading about the mathematics behind signal processing, and a book that gets recommended a lot is "Mathematical Methods and Algorithms for Signal Processing" by Todd Moon and Wynn Stirling.

However, this book seems to have a huge list of errata (people speak of over 40 pages) and there apparently never was a new edition after it came out over 25 years ago. What makes this worse is that the book's website with the errata is not online anymore, and given the steep price of the book, I don't want to pay that for a book with that many errors and no access to the errata.

Do you have recommendations for other good books covering the same material?

Thanks!

I'm modelling the TR-909 the way I modelled the 808 and 606 before it: component by component from the service notes, with one hard rule - no fitted or matching EQ anywhere. Every filter, every time constant, every gain in the model has to trace back to a component that is drawn on the schematic, or it doesn't ship. Validation is against recordings of real units (multiple machines where I can get them), but the recordings are the gate, never the source: when the drawing and a recording disagree, I don't get to turn a knob until they agree. I have to find out why.

That rule is what made the following visible, because without it I would have EQ'd the discrepancies away in an afternoon and learned nothing. As the model got close - close enough that the remaining deviations were a dB here, a few percent of a time constant there - the residuals stopped looking like noise. They grouped. Specifically, they grouped by what the component that owns each parameter is made of.

Time constants owned by tantalum capacitors read consistently long, by 14 to 19 percent, on every unit measured. The 909's tom body decay is set by a tantalum; every reference unit decays 14-19% slower than the drawn RC says it should, and they all miss in the same direction.

A recovery time owned by an aluminium electrolytic reads consistently short. The hand clap has a roughly 228 ms recovery between hits set by an electrolytic; on both units I could measure, the effective capacitance comes out around 0.83 times the drawn value. Electrolytics dry out and lose capacitance - this is the single best-documented aging mechanism in the business, and it points exactly this way.

A clock frequency owned by a carbon-composition resistor reads consistently high, by about 16 percent - on four different machines. Carbon comps drift upward with age, heat and humidity; four units agreeing on the direction and roughly the magnitude is not a lottery.

And the control that makes this believable: not everything drifts. The kick's poles sit dead on the drawn values across units. Film caps and metal film resistors holding their values while electrolytics sag, tantalums stretch and carbon comps climb is exactly what a 40-year-old PCB should look like. If every parameter had missed, I'd have suspected my own readings of the schematic. The residuals sorting cleanly by dielectric and resistor construction is what flipped my interpretation: these aren't model errors. The model was measuring the age of the reference units.

Which lands you somewhere genuinely strange for validation. The schematic describes the machine Roland built in 1984. Every recording anyone can make today describes a machine that has been drifting away from that schematic for four decades - and drifting coherently, because the same chemistry is running in every unit. So a model that is exactly right by the drawing will sit at a small, systematic, same-signed offset from every reference you can buy or record. If you validate purely by fitting to samples - which is the industry default - the fit will happily absorb one particular elderly unit's drift, your metrics will reward you for it, and you will ship "authentic 1984" with today's electrolyte chemistry baked in.

Edit:

After listening more and more, i prefer the old values, Toms and Kick have more sustain, it just sounds more alive and less stiff.

Question for the room: has anyone treated component aging as a first-class model parameter rather than a nuisance? Tape emulations have had "worn" controls for years, but those are usually designed sounds, not chemistry-driven parameter drift. And if anyone has good literature on solid tantalum capacitance drift over multi-decade timescales, I'd genuinely like to read it - the electrolytic and carbon-comp stories are textbook, but the tantalum shelf is thinner, and right now my 14-19% is a measurement in search of its chemistry paper.

Disclosure: I make a commercial drum plugin, this work is in it.

Edit: I could be wrong about aging being the only reason of what i'm measuring and hearing. It could very well be that component tolerance is the cause of this. Anyways, the conclusion is to not always trust the values on schematics 100% since there are quite some factors that could cause components to be off just enough to sound a bit different from the hardware, even though the math is correct according to the circuit.

I guess this is only tangential to DSP, it’s more on the business side of things anyway.

I am a software contractor but haven’t had a contract since October due to the economy and I guess AI takeover, and now money is starting to run out completely.

I decided to finish a soft synth I’ve been working on a few years back and it’s starting to be ready for release.

This is not my first audio DsP project but it is the first one to try and sell.

I’ve found some places where you can sell online and get an API for licensing, like Gum Road. But I am sure there must be thousands of options to go about this where one or two are the ones that will actually make money.

I don’t have the time, money, or motivation to self publish and market this myself.

So what are the best options?

A completely different thing I want to check with people who do this for a living. I’ve measured aliasing by generating different frequencies with my(polybleped) oscillators, then cut out the fundamental frequencies and measured the dBRMS at different oversampling ratios. But I’m not sure what’s an acceptable level for the higher keys to be considered pro level aliasing. So if someone has some insight here I would be happy to receive some advice too. At note C8 I’m only reaching about -30dB using 2x oversampling, at 4x -50dB and 8x -70dB, so I have to make a judgement call here. But it’s 16 voices and analog modelled oscillators so it’s quite expensive to run even with SIMD and -ffast-math.

Thank you

This video showcases my software recreation of the legendary Waldorf Wave—a hybrid wavetable synthesizer known for its huge digital oscillators, analogue filters and unusually complex hardware architecture.

The project is built in C++ using JUCE and is available as a standalone instrument and plug-in. Rather than simply making a modern synth that sounds similar, I’ve tried to reproduce the structure and behaviour of the original machine.

The emulation models:

• The Wave’s 250 kHz, 8-bit time-multiplexed wavetable oscillator system
• Signed mixer overflow—including the characteristic Waldorf “ASIC Mix Bug”
• Digital 12 dB high-pass filtering
• CEM3387-style reconstruction filtering, resonant four-pole low-pass filtering, VCAs and panning
• 12-bit stepped control voltages, sample-and-hold behaviour, saturation, noise and output coupling
• Three independent 16-voice WDV boards, matching a fully expanded 48-voice Wave
• The original 480 × 64 monochrome LCD and front-panel workflow

The instrument can also run authenticated Waldorf Wave OS 1.700 firmware. An emulated 68000 CPU executes the original main operating system, while a second runtime executes the genuine WDV voice-board program. Their shared-memory communication, voice-update masks, semaphores and hardware-register writes are reproduced and traced inside the model.

The oscillator ASIC itself remains undocumented, so its internal operation is represented by a behavioural model based on the Wave’s published architecture, firmware activity and known hardware characteristics. This is therefore an ongoing reverse-engineering and preservation project—not a claim of perfect, bit-exact emulation.

Waldorf and Wave are trademarks of their respective owner. This independent project is not affiliated with or endorsed by Waldorf Music.

🔬 I have data from devices that are WITH YOU RIGHT NOW. If you can decode the protocol, I'll reveal what they are.

The Challenge

I'm conducting scientific research and need independent validation of my findings. I have collected multi-channel time series data from devices that are physically present in your daily life - you've probably used them today.

Here's the deal:

• I've fully anonymized the data (no hints about frequencies, physical meaning, or source)
• If you can independently discover and decode the communication protocol hidden in these signals
• I will reveal exactly what these devices are
• And trust me - you'll be surprised

What You Have

Dataset:

• 15 parallel channels (Channel_01 to Channel_15)
• 5 operating modes (Mode_A through Mode_E)
• 2 devices: Device_A (control) and Device_B (test unit)
• Sampling rate: 256 Hz
• Duration: ~15 minutes per mode
• Format: Compressed .npz files (~10 MB total)

Your Mission:

1. Determine if there's a deterministic communication protocol in the data
2. Identify its parameters (time slots, routing patterns, encoding)
3. Find differences between Device_A and Device_B
4. Analyze how protocols differ between operating modes

What Makes This Interesting

If you successfully decode the protocol:

• 🏆 Your name credited in the research publication
• 📝 Co-authorship for significant contributions
• 🔓 Full revelation of what these devices actually are
• 💡 Acknowledgment that you independently discovered something remarkable

Even if you don't crack it completely:

• Interesting data to play with
• Chance to develop novel analysis techniques
• Opportunity to collaborate on cutting-edge research

Included:

• Compressed data files (.npz format)
• Python loader scripts
• Visualization examples
• Basic analysis tools

The Rules

1. Work independently (or in teams, your choice)
2. Share your methodology and findings in comments
3. No peeking at my results (I won't share them until challenge ends)
4. Have fun! This is supposed to be interesting

Why I'm Doing This

Science needs independent validation. I have strong evidence of a hidden protocol, but confirmation bias is real. By releasing anonymized data to the community, I ensure that any discovered patterns are real, not artifacts of my expectations.

If 3+ independent analysts find the same protocol structure, that's proof.

Questions?

Ask in comments. I'll respond to methodological questions but won't give away hints about the solution.

Let's see what this community can discover! 🚀

TL;DR: Anonymous multi-channel data from everyday devices. Hidden protocol inside. Decode it → get credited + learn the surprising truth. Independent validation needed for scientific research.

Hello everyone, i know very little about DSP on a tecnical level. I am studying to become a sound engineer, but in terms of DSP what i have been taught is that typically expensive proprietary solutions are the only viable ones.

Now, i got the impression that DSP the cheapest chipsets for audio would go at around 30$. But why couldn't i build, say, a PCB out of any of the 3$ to 6$ chips that appear in the first page of the DSP section on DigiKey.

I know that i am not understanding this, so i post here to ask so that i can understand.

Edit: i saw quite a few comments asking me to list my hardware requirements, which makes a lot of sense so here we go.

A beginner student or amateur board for multitrack recording. instead of going very deep, going wide with only 14 to 16 bits audio depth, but 8 to 16 recording lanes at 44.1 or 48khz, which can be plugged into a computer for direct recording, or have an sd card plugged in for portable recording.

Hello all, here is a chill post.

When I was an undergrad, I really liked working things out on a whiteboard. Drawing stuff, talking through ideas out loud, testing little hypotheses.

Now I work in radar DSP, and a lot of my work is code, numerical experiments, deep learning and waiting for training to finish 😅

I’m wondering how other people bring that whiteboard style of thinking into DSP, data science or ML work.

Do you still use a whiteboard regularly, or do you mostly go straight from idea to code?

I've been building a synthesizer in pure x86-64 assembly (self-taught, from a languages background), and the real challenge turned out to be the DSP: implementing the classic effects from first principles, in fixed-point, with no FPU and no math library.

So far: a Schroeder reverb (parallel comb filters into series allpass), a state-variable filter for an auto-wah driven by an envelope follower, a supersaw using 16.16 fixed-point phase accumulators to detune voices, plus delay, chorus, flanger, phaser, hard sync, and phase distortion.

I leaned on the canonical references — Julius Smith's CCRMA materials, the DSP Guide, the RBJ cookbook — and then had to make it all work in integer math.

Rendering, listening, and debugging "why does this alias / click / go silent" taught me more than any single text.

Everything's public on my GitHub: https://github.com/whispem

Would love feedback or war stories from people who do this seriously.

Over the past year I've been building Img2Num, an open-source C++ library that converts raster images into SVGs, with Python, JavaScript, and C bindings.

The motivation: existing vectorization tools are really built for line art, logos, and scans - clean inputs with hard edges. I wanted something that could handle natural images (photos, textures, noisy real-world content), and that turns out to be a very different problem. You can't just trace what's there, because what's there is full of sensor noise, JPEG artifacts, and gradients that explode into thousands of junk paths. So the vectorization step ends up mattering less than the signal processing in front of it.

The rough pipeline: edge-preserving denoising with a bilateral filter (selectable between RGB and CIELAB - perceptual color spaces make a real difference in how edges survive), k-means color quantization, Suzuki-Abe contour tracing, and then Savitzky-Golay smoothing applied to the traced contours. That last step was the fun one: treating a closed contour as a pair of periodic 1D signals (x(t), y(t)) and filtering them means you can smooth out pixel staircase noise while preserving corners far better than naive moving averages, and SG's polynomial fitting is a good match for that.

The part I'm still iterating on is adaptive preprocessing - estimating noise per image (wavelet MAD estimator) and tuning the denoising strength accordingly, so the traced regions stay stable instead of speckle turning into hundreds of junk paths.

Everything is on GitHub and installable via pip and npm (both "img2num"), docs at img2num.dev. I would genuinely love feedback from this crowd (the DSP crowd), especially on the smoothing and noise estimation choices - I came at this from the software side and learned the DSP as I went on.

Im a new grad im on the first round for an interview, its very heavy DSP-oriented, any advice on what to study/focus on? any common interview questions asked? Focus is more on the RTL, FPGA, ASIC, or Firmware areas

Thanks!

JD (ik its more RTL digital design focused but the recruiter was heavily asking about my DSP experience)

• BS and a minimum of 3 years relevant industry experience
• Some level of fixed-point knowledge and experience with bit-true verifications
• Understanding of DSP communication algorithms and trade-offs between performance and complexity
• Good knowledge in modern design techniques and energy-efficient/low power logic design
• Ability to work well in a team and be productive under aggressive schedules
• Excellent communication skills and self-motivated

Hi everyone,

I’ve created a beginner-level AGC (Automatic Gain Control) model for an ISP as part of my learning.

I’m facing some issues in my current design, and I’m not sure what the best way is to improve it. If anyone has experience with ISP or AGC design, could you please check my repository and give me some feedback?

I’d especially like help with:

• Finding the problems in my current design
• Understanding why these issues are happening
• Improving the AGC algorithm and architecture
• Understanding how I can upgrade this beginner-level model into a more practical design

Here is my repository: github

Any suggestions, feedback, or guidance would be really appreciated. I’m trying to learn and improve the design, so even small suggestions would be helpful.

Thanks in advance!

Hi, as in the topic. I am third-year microelectronis student. I know basics about dsp and analog signal processing. i am into firmware engineering, also working right now as a junior digital design/verification. I want to dive into digital synth/effects world as my bachelor degree and i am looking for resources (books (would be the best), websites, channels on yt etc.). I can use google ofc, but if you have some places which are really worth checking, let me know. Really everything - from mathematical view to more hardware specific. For now i just made simple sequencer, with pitch modulation on ESP32, which can be connected via serial to simple wave synth made in LabView. My goal is a groovebox (didnt specifed functionality yet but thinking about everything right now, from EQ to sampling, sequencing, but synthesis and optimized firmware is my main goal, i know chaos, but just to give you my interests) with a custom stm pcb. Thank you

I tried so many ways to find the online pdf of this book I mentioned. But all are paid. I badly need this book. If anyone have any source to download the pdf of the book, please help by sharing with me.

Edit. IT is Sanjit K. Mitra

I built an S-Parameters plotter that runs entirely in the browser.

What it does:

• Drag-and-drop or upload any Touchstone file, .s1p through .s9p (n-port, not just 2-port)
• Auto-detects format — handles MA, RI and DB, both Touchstone v1 and v2, and whatever frequency unit the file uses (Hz/kHz/MHz/GHz)
• Plot magnitude (dB or linear), phase, or real/imaginary vs frequency
• Load multiple files at once and either overlay them on one chart or view them separately — useful for before/after de-embed comparisons, or comparing simulated vs measured data
• Toggle individual Sij parameters on/off (for higher port-count files this actually matters, nobody wants all 16 S-parameters of a 4-port on screen at once)
• Data table view with copy-to-CSV, and you can re-export the loaded data back out as a Touchstone file
• Nothing gets uploaded anywhere — it all runs client-side in your browser

Free, no signup: https://rfstudiolabs.com/sparams/sparam-plot.html

It's part of a small set of S-parameter tools I've been building (Smith chart with auto-matching, cascade calculator for chaining 2-port networks, a de-embedding tool, amplifier stability/K-factor analyzer) if anyone's curious: https://rfstudiolabs.com/sparams/index.html

If anyone has a Touchstone file that trips it up (weird formatting, non-standard option line, whatever) I'd genuinely like to know — send it my way and I'll fix the parser.

Hello, I'm doing a project on an FPGA for image processing. I'm at the stage where I've finished the verilog and already have the hex files generated, what I want to do is to compare that to my matlab floating point reference. Since, both are images, what metrics are best used for their comparison? I vaguely remember from a course where we determined the floating point vs fixed point error using LSBs, so like there would be an error of +/- 2 LSBs for example, but that was on 1D data. I dont know if thats still the case here for images.

I found bandpass spectrographs 20 years ago with a random experiment in Reaktor from native instruments, I thought it was nicer than FFT and Wigner TF. So many years later here is a web version on html, https://www.youtube.com/watch?v=TwaQORBks8Y < Funny video ;)

I am working on a digital beamforming project with goal of implementing 8 antenna- 4 beam. I started with a simple 8 Antenna - 1 Beam , assuming a fixed DOA , 1 GHz carrier frequency, AWGN/noise, no interferers, and 10,000 samples. I implemented both floating-point and fixed-point DRC-pLMS, generated test vectors, performed RTL functional verification, synthesized the design using Genus, and performed gate-level simulation. The Python, RTL, and GLS results currently match, including the final weights and beam peak.

The issue is that my pLMS formulation uses a known desired/reference signal. In my simulation, I generate the original transmitted signal, so I can also generate the reference signal and use it for adaptation. However, in a practical receiver, if the transmitted signal is unknown, knowing only the desired DOA does not give me the actual instantaneous reference waveform. Therefore, I am concerned that my current reference-based pLMS approach may not be suitable for the intended real-world beamforming application.

My question is whether the work I have done so far is still a valid and should I move forward or try different algorithms, am I even doing things correct. Can I move forward any form of assurance or clarification is highly appreciated.

*used LLM for grammar