Hello all,

I'm a radar signal processing engineer and i trained a 5-class classifier (car, large_vehicle, two_wheeler, pedestrian, pedestrian_group) on RadarScenes radar point clouds.

The input vector is a per-scan histogram (16 bins) and the network is a 3-layer MLP. The loss function is a class-weighted cross-entropy loss. This work is based on "Histogram-based Deep Learning for Automotive Radar" paper.

I scoped the project to be one scan only. Accumulation of multiple scans is the next step.

Data

Class Imbalance: two-wheelers and large_vehicles has a low number of occurences.

Aggregated Classes: two_wheeler mixes bicycles and motorized variants; large_vehicle merges trucks, buses, and trains together due to data scarcity.

Sequence Bias: Long tracks of slow-moving objects can skew a particular data split velocity distribution, causing high F1 score variance across folds.

Ablation studies

I tried with bigger MLPs, alternative feature encodings, and different histogram binning, all moved performance less than the variation caused by changing the train/validation/test split. I measured that split sensitivity across 6 folds, keeping the same proportions.

Changing the histogram to per-instance statistics (mean/median/std) slightly degraded performance.

Main findings

Macro F1 rises from 0.381 to 0.764 as the naturally occurring number of radar detections per instance increases from 1 to 5. I trained the model normally using all available detections, then bucketed its existing validation predictions by each instance's detection count and computed macro F1 per bucket.

The classes car and pedestrian has the best performance and two_wheeler has the worst.

A car is often confused as large vehicle when the car was wider than usual or had a unusually high rcs (which can happen due to multipath for example).

The two_wheeler is often confused as pedestrian because their vr_compensated distributions overlap, which is the the model's single most important feature for these two classes. A stationary or idling two_wheeler is indistinguishable from a pedestrian.

I uploaded an image with ground truth vs predictions: A nearly stationary two-wheeler which contains a single point was predicted as pedestrian, because its velocity is near zero, indistinguishable from a pedestrian. A car in the same scene, also with just one point, is classified correctly, since RCS and Doppler are enough for that class.

Full writeup here: https://github.com/brunopinto900/radar-ml-autonomous-driving/blob/main/MLP_Report.md

Future work

Implement other spatial encoding schemas (point net for example) and accumulate multiple scans to tackle the challenge of sparsity and explore the concept of micro-doppler.

I know how to solve but i just can't think of solving circular convolution for origin being anywhere like how to solve for a sequence say

x[n] = [2,-1,3,4] with origin say at element -1

and h[n] = [-2,1,3,2] with origin say at element 1

do i have to make both the sequences start from 0 to calculate it and then solve the outputs index or

should i first calculate the circular convolution then solve the indexing?? if i shift the indexing first creating 0 to N-1 sequences then solving the index then my resultant is

y[n] = [7,-4, 7, 22 ] with origin at element 2nd 7 (3rd from starting)

but if i take the latter approach then i get

y[n] = [7, 22, 7, -4] with origin at 2nd 7 (3rd from starting) but -4 and 22 have swapped

please tell me how to do this !!

I'd **like** you guys to **look** at the first **project on my page**. In terms of **remote sensing, signal detection and machine learning** is there a **cheaper** way to **separate noise** (clouds) from **signal** (landmass) in the industry? Just **looking** for an opportunity to **learn** here :)

Thanks!

KPK

I'm looking for the old RG-2016.4 XtensaTools files.I already have Xplorer and a legit Cadence license, just missing the old toolchain.

If you have an old installation/archive of RG-2016.4, or know someone who might still have it, please let me know.

Thanks!

MidSide: a Basic Audio Utility and an AI Coding Test

Two honest answers to “Why build a Mid/Side plugin?”

One: we had a workflow improvement goal that existing plugins didn’t solve
Two: we wanted to know if an AI coding agent — Claude Code — could build a real plugin, not a toy demo.

The net results? We built a DSP bit accurate signal processor and at the same time a plugin development pipeline. Download free to try the results. Input on refinements appreciated.

As title asks.

I’m basically asked for the range of n values for which y[n] (convolution of x[n] *h[n]) isn’t in either a transient or end effect? Would it be all ranges where y[n] remains a flat line of 0? Any ranges where y[n] remains a flat line at any finite value (zero slope through it)? Something else?

Already solved for convolution results via tabular approach, but these weren’t covered in class, so I was wondering if I could get clarification on these 2 effects.

I'm developing a local file player and I'd like to add visualizations.

Pls check out my peak meter and tell me what you think, how does it feel?
https://www.youtube.com/watch?v=gU-F0A5NOEE

I made it off a photo and shaky videos of an old tape deck, it's supposed to mimic a VFD display.
I don't have any real hardware available to compare so I figure maybe someone has actually seen one.
This is the first time I'm working with audio, just making web software and photos otherwise. Thx! :)

Hello! I'm designing v2 of my digital mixer, which uses an ADAU1466, ADCs, DACs, and an ESP32-S3 for the web interface.
So far so good. V1 is working great, but for V2 I'd like to add multi track recording to an SD card.

I basically under-researched the ESP32 I2S capabilities, and I can't use the 8ch/32bit I was hoping to to use a single output serial port for the 8 channels.

I knew I'd be limited to 16 bits, which is good enough, besides the little missing detail that I cannot configure the serial port that way in SS. I can only choose 32 bits for 8 channels.

So, since I've already sent the PCBs for fabrication (silly me, I know) I thought of packing the two channels into one output in the schematic, but I'm kinda lost on how to do it, or even if it is possible.

Any resources or hints would be greatly appreciated.

Thanks in advance!

Hey everyone...I wanted to solve some faced by the industry in the field of speech processing...Could the people who work in industry please list down problems faced ??

Consider two systems: one has an ADC, and one has a DAC. Both are connected via a wire. How do I calculate the SNR of the Channel?

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.