I've noticed a strange audio artifact in Roblox, especially in older games/weapons that rapidly retrigger short sound effects.

At lower rates, I hear the individual sound events normally. But once the sound is retriggered rapidly enough, a separate continuous tonal/harmonic sound appears underneath the SFX. It sounds roughly F#, and it behaves almost like a background hum or ringing generated by the audio system.

The strange part is that it doesn't seem to behave like ordinary repetition pitch. Increasing the firing/retriggering rate further doesn't simply make the tone continue rising in pitch. After crossing a certain density, the underlying tone remains approximately stationary while the individual sounds continue being retriggered.

I've reproduced it with very different Roblox sounds: rapid gun SFX (including a modded gun using different samples) and an unrelated rapidly repeated punch/impact SFX. The same kind of underlying tone is audible in both.

48,000 / 1024 = 46.875 Hz, but I don't know whether that's actually related to Roblox's audio processing or is just a property/artifact of my recording chain.

Does anyone familiar with Roblox's audio engine know what could cause this? Is there some voice scheduling, mixing, block processing, quantization, clipping/limiting, or other DSP behavior that becomes audible when Sounds are retriggered extremely rapidly?

Hello all,

I built a radar object classifier on RadarScenes, extending a prior single-scan classifier to accumulate observations over a tracked object's history instead of classifying each scan in isolation.

A single RadarScenes object instance contains only about 2.9 radar points on average, very sparse. A single scan also can't capture temporal characteristics: RCS and micro-Doppler both vary continuously as an object moves. Pedestrians produce characteristic micro-Doppler from limb motion; different object classes show different RCS fluctuation patterns as aspect angle and scattering geometry change scan to scan. Accumulating observations gives both higher point density and provides temporal dynamics.

Multi-scan baseline

DeepReflecs encoder (Ulrich, Glaser & Timm, RadarConf 2021), PointNet style, per point shared weights, on single scans across car, large_vehicle, two_wheeler, pedestrian, pedestrian_group: 0.7370 macro F1.

Using RadarScenes' persistent `track_id`, I build a causal, N=20, per track sliding-window buffer:

- x_seq/y_seq: Global, odometry-corrected coordinates recentered per scan on the object centroid. Unlike x_cc/y_cc (car-frame coordinates that accumulate over time to form a trajectory).

- Cross sensor buffer: whichever of the 4 sensors currently observe the track push to the same buffer.

- Stride 1, causal: every new scan updates the buffer and produces a prediction. No future context, real time streaming compatible.

- Each scan is encoded once by a frozen per scan encoder and cached

- Fusion concatenates the causal GRU's hidden state (order aware) with an order-invariant pooled embedding (all N scans' points as one set, no sequence structure) through a small trained mlp head.

Results

Model	Macro F1	Delta
Single scan	0.7370	(baseline)
20 scan point pooling	0.8613	+0.1243
Causal GRU	0.8895	+0.0282 over pooling
GRU + pooled embedding (fusion)	0.8897	+0.0002 over GRU, noise

Pooling alone, no sequence model, no notion of scan order at all, recovers +0.1243 macro F1. The GRU adds a real but much smaller +0.0282 on top. Fusion adds nothing measurable beyond the GRU.

Ablation

Llarger GRUs, a Transformer, a state space model, point level self attention, all trained on the exact same frozen per scan embeddings, land inside a 0.86 to 0.89 band, a 0.03 spread. End to end fine tuning of the frozen encoder makes things slightly worse (about -0.002 to -0.003), not better.

Conclusion

In this setup, the largest gain comes from giving the model more observations of the same tracked object: 20-scan point pooling improves macro F1 from 0.7370 to 0.8613 without using scan order at all.

Temporal modelling then provides a further, meaningful improvement. The causal GRU reaches 0.8895, adding +0.0282 over the pooled representation. So temporal ordering clearly contributes useful information; it just accounts for a smaller portion of the overall gain than observation accumulation.

With the per-scan encoder frozen, the different sequence architectures tested, suggests that the quality of the per-scan representation is the bottleneck than the particular mechanism used to aggregate the sequence.

Full report, every ablation, confusion matrix, coordinate frame reasoning: https://github.com/brunopinto900/radar-ml-autonomous-driving/blob/main/final_report.md

Thank you.

I keep finding myself when doing sound design trying to either take what I would describe as a grainy gritty sound and making it smooth and glassy, or vice versa and taking a smooth and glassy sound and trying to make it sound more gritty and grainy in particular with synthesizers.

I'm trying to understand more what imparts these particular qualities. For examples, see below.

But here are my overall questions.

1) If you were a synth designer, and you wanted to give your synth a grainy gritty quality... how would you set things up to give it that character?

2) Vice versa, if you wanted to make your synth more glassy and smooth, how would you go about that?

3) if you wanted to switch from one to another via mixing? How would you approach it?

EXAMPLES:

This synth Chipsynth MD emulates an older sega genesis FM chip, and the underlying mechanics of it originally being a physical electronic hardware chip at a lower bit rate imparts more of a gritty character to a fair amount of sounds. (but you can get to a smoother sound with certain patches).

Whereas Zebra 3 and Zebrallete have a much smoother glassier sound in general to the majority of their synth presets. (but you can still get a grainy texture for some presets). For extremely smooth and glassy, this synth, FM lab i would consider on the extreme end of that. (yes I know that certain types of FM specialize in this type of quality)

Something in between might be this... MPowersynth... the synth sort of has this grainy texture for a majority of sounds, but there's something they are doing on the back end to impart some sort of character... to make the high end frequencies smoother at the same time as having some harshness in the mids as most of the patches tend to have that character.

Can anybody help me with this issue I'm facing in generating sine waves?

Has anyone ever written a custom FPGA SPI master state machine to completely initialize the AD9361 by doing register level writes? I want to get in contact with somebody who has done before this hardware level control of AD9361.

I teach an undergraduate Signals and Systems course and have been developing the lecture material as an interactive browser course. It covers signals and systems, LTI systems and convolution, Fourier series and transforms, and sampling and aliasing.

The current version has 531 scenes, 35 interactive labs, and 210 practice questions with worked solutions. It runs in the browser, and the site also has printable lecture notes, a question workbook, and a formula reference. Python examples run in the browser when selected.

Course site · GitHub repository

If you teach or study DSP, I’d be interested to hear whether the interactive labs and worked questions are useful, and what you think is missing.

https://reddit.com/link/1wuebkx/video/xm95ods9npsh1/player

I want process every onset note from song.wav in C/C++. Is using frequencies a good idea, if program must process every note separatelly?

Hello,

I am currently working on a project where I have to calculate the LF power from a reBAP blood pressure signal. I was instructed to use Wavelets for this task, so I've been trying to figure them out. After some research, I learned that orthogonal wavelets are better for energy preservation, so I thought maybe I'll use orthogonal wavelets because I feel like energy preservation would be important for calculating LF power of the signal. However, after more research, I learned that the orthogonal wavelet scales are only in powers of 2. So, then I think the frequency resolution is too sparse to capture the frequencies within the LF band, which ranges from 0.04 - 0.15. So then I feel like continuous wavelet transform might be a better choice because the frequency resolution is much finer. But CWT doesn't have the energy preservation that the DWT has. I'm new to signal processing and I'm not sure if any of my reasoning here is even correct. I would really appreciate any advice about how to move forward.

Thank you!

I am working with multichannel upper-limb sEMG recorded at 2 kHz. I plotted the PSD/Welch spectrum for individual recordings and observed that some recordings show a very sharp peak around 50 Hz across multiple channels, while other recordings do not show an obvious 50-Hz peak. I also compared the raw signal, 20–450 Hz band-pass filtered signal, and 50-Hz notch + 20–450 Hz filtered signal.

My concern is that 50 Hz can contain genuine EMG energy, so applying a notch filter might accidentally remove physiologically meaningful information. On the other hand, a narrow and strong 50-Hz peak across many simultaneously recorded channels could indicate power-line interference.

I’ve been working through an audio/DSP idea that I think may be useful enough to throw out to people who actually write plugins, physical models, resonators, modal processors, etc. I’m not planning to build or sell this myself. I’m posting it because I’ve now prototyped the basic concept in a DAW in more than one way, the audible result is surprisingly convincing, and I think there may be a useful product idea hiding in something that is conceptually very simple:

A lot of virtual instruments reproduce the note very well, but they do not fully reproduce the physical object that produced the note.

I’m calling the idea:

INSTRUMENT BODY

The simplest possible signal model is:

SOURCE / EXCITATION

→ INSTRUMENT BODY

→ ROOM / ENVIRONMENT

→ MIX

The important part is that Instrument Body is NOT supposed to be room reverb. It is supposed to represent the acoustic behavior that belongs to the instrument itself before the room ever gets involved. That distinction is basically the entire idea.

WHY I STARTED THINKING ABOUT THIS

Piano is what made the problem obvious to me. I can try a piano VST with good samples, lots of velocity layers, good hammer detail, good tuning, good recording quality, good stereo imaging, and good noise modeling, and still reject it because the complete instrument sounds physically tiny.

The individual notes may sound perfectly respectable, but the whole thing can still sound like 88 samples instead of one large acoustic machine. The recurring problem is that the piano sounds thin, small, weak in parts of the keybed, synthetic, disconnected, or like a note generator rather than a large vibrating object.

My reaction is basically: “Where is the piano?”

Putting room reverb on it often does not fix that. It can simply become a small synthetic-sounding piano in a large beautiful room. That suggests that the missing thing is not the room. It is something earlier in the signal chain.

THE PHYSICAL DISTINCTION

A physical piano is obviously not just a string followed by a room. The hammer excites a string. The string transfers energy through the bridge. The bridge excites the soundboard. The soundboard interacts with the frame, case, other strings, air around and within the structure, etc.

That energy does not all disappear at the same rate. Different parts of the spectrum store and release energy differently.

A guitar has the same basic issue on a smaller physical scale. So does a violin, cello, mandolin, upright bass, harp, and a lot of wooden percussion. The body is not simply packaging around the source. The body is part of the source.

I would simplify conventional room reverb as:

source → propagation through space → reflections → increasing reflection density → environmental decay

Instrument-body behavior is more like:

excitation → structural coupling → resonant energy storage → frequency-dependent radiation → frequency-dependent decay

That second process should begin essentially at t = 0. There should not normally be an obvious room-like predelay because nothing is waiting for sound to travel to a wall and return. The body is responding while the note is being created.

A REALLY SIMPLE REAL-WORLD TEST

Knock on a piano and listen to what the physical object does after the impact. Then knock on an acoustic guitar. Then a mandolin. The response is obviously different.

A large piano structure can continue speaking for a surprisingly long period after the excitation. A guitar body responds much more quickly. A mandolin is faster again.

I’m not claiming there is one fixed “piano decay time” or one fixed “guitar decay time.” That would obviously be nonsense. Construction matters. Size matters. Where you hit the instrument matters. Material matters. Bracing matters. Bridge design matters. Geometry matters.

But the basic point is very easy to hear: the physical instrument has a time-domain response of its own. The body stores energy, then it gives that energy back.

WHY I DON’T THINK ORDINARY REVERB IS THE RIGHT MODEL

My first prototype actually DID use reverb. I took a very dry virtual piano and put a short, dense plate-style reverb directly in series with it before the actual room stage. I used essentially no predelay because I wasn’t trying to represent external propagation. The goal was just to make the dry source acquire immediate resonant persistence.

That worked much better than I expected. When I bypassed the plate, the piano seemed to shrink.

But there was an obvious limitation: a conventional reverb fundamentally wants to impose a broad decay behavior on the incoming signal. A real instrument body does not appear to behave that way. Its persistence changes with frequency.

That led to the part of the concept that I think matters most.

THE TWO FUNCTIONS I THINK MATTER MOST

For a first-order model, I think most of the useful perceptual behavior may boil down to two frequency-dependent functions:

Peak(f)

Decay(f)

Peak(f) answers: “How strongly does this spectral region participate in the body response?”

Decay(f) answers: “How long does energy in this spectral region remain active?”

Those are NOT the same thing. More bass level is not the same thing as longer bass decay.

A region can have high amplitude and short persistence, or moderate amplitude and long persistence. So I would not try to fake this with one EQ curve. I would treat amplitude response and decay response as separate internal functions.

THE SECOND PROTOTYPE

I then made a more explicit multiband approximation. My current crude version only uses four bands. Each band has its own resonant/modal behavior and its own approximate decay characteristic.

It is nowhere near a complete physical model. It is crude. But it works surprisingly well.

That is what made me think the concept may be more important than the implementation.

The first experiment used spectrally separated reverb behavior. The second used multiband modal/resonant behavior. Both produced the same basic perceptual result: the instrument acquires more apparent physical mass without necessarily sounding like it has more room reverb.

That makes me think this may not require an extremely complicated physical simulation. The ear may be responding strongly to a small number of first-order physical behaviors.

WHAT I AM HEARING WITH PIANO

My current ear-derived working references are roughly:

32 Hz → about 1.5 seconds

3.2 kHz → about 0.4 seconds

Those are NOT laboratory measurements. They are just current prototype target values that sound convincing to me.

My first conceptual decay curve assumed that decay would just keep getting longer as frequency went lower:

80 Hz → 1.60 s

125 Hz → 1.45 s

200 Hz → 1.30 s

315 Hz → 1.15 s

500 Hz → 1.00 s

800 Hz → 0.85 s

1.25 kHz → 0.72 s

2 kHz → 0.60 s

3.15 kHz → 0.48 s

5 kHz → 0.37 s

8 kHz → 0.28 s

12 kHz → 0.20 s

That looks neat on paper, but when I actually tuned the prototype, the extreme low end did NOT want to keep getting longer. At around 32 Hz I ended up around 1.5 seconds, roughly flat relative to the 80 Hz area and maybe even slightly shorter.

That made me think Decay(f) probably should NOT simply increase indefinitely toward DC. A more realistic shape may be:

low-frequency rollover → region of maximum persistence → progressively shorter high-frequency decay

That makes intuitive physical sense. At some point the wavelength becomes too large relative to the finite structure. A real soundboard cannot keep supporting increasingly long low-frequency behavior forever. So there may be a low-frequency knee.

THIS IS WHERE SIZE MAY BECOME REALLY IMPORTANT

If that low-frequency rollover is real, instrument size may do something much more interesting than just “big instrument = more bass.”

A smaller body may reach its low-frequency limit earlier. A larger body may support useful body persistence farther downward.

So instead of Size being a cheesy macro that just increases decay time globally, Size might actually move the shape of Decay(f):

SMALLER BODY → low-frequency rollover occurs higher

LARGER BODY → low-frequency rollover extends lower

That is testable.

For example:

small upright piano vs concert grand

mandolin vs guitar vs cello vs upright bass

I would be very interested in whether the timing relationships are even approximately scalable with physical dimensions. They obviously won’t be perfectly linear because the construction differs, but I don’t need perfect physics. If physical size explains a large enough percentage of the perceptually important timing difference, that could massively simplify presets.

POSSIBLE SIZE MODEL

A later version could use:

X = length

Y = width

Z = depth

Not because a violin is literally a rectangular box. The box would just represent physical scale and proportions.

A GUI could show a little 3D body volume and let the user size it approximately to the instrument. Internally those dimensions could potentially influence decay-time scaling, low-frequency rollover, modal density, spectral response, and eventually stereo radiation.

For a simple V1, I would probably NOT expose XYZ. I would start with:

Small

Medium

Large

Or instrument-specific choices where standardized sizes already exist.

Violin: 1/2, 3/4, 4/4

Guitar: Parlor, OM, Dreadnought, Jumbo

Piano: Upright, Baby Grand, Medium Grand, Concert Grand

If the underlying scaling relationship works, those size choices could modify one common family model rather than loading completely unrelated DSP for each preset.

ANOTHER IMPORTANT VARIABLE: COUPLING

There is another thing that became obvious while working on the piano prototype: there is not necessarily one single correct Decay(f) curve for “a piano.”

The coupling state matters.

Compare normal damped playing with prolonged sustain-pedal use. With normal damping, strings are stopped in the usual way. With sustained or undamped behavior, much more of the string system is available to participate sympathetically. The instrument becomes more interconnected and energy has more opportunity to persist and move through the system.

So I now think a useful piano model may need at least two reference conditions:

NATURAL / DAMPED

EXTENDED / SYMPATHETIC

Natural would represent normal damper behavior. Extended would represent a more open, sustain-heavy, sympathetic condition.

I would probably represent that internally with a control I’m currently calling COUPLING:

Natural <-------> Extended

Coupling is not the same thing as Richness.

Richness would mean: “How much body response do I want?”

Coupling would mean something more like: “How interconnected is the modeled resonant system?”

For a piano it might modify low-frequency persistence, neighboring resonant-band interaction, sympathetic behavior, and perhaps the shape of Decay(f).

I’m not sure this even needs to be exposed on the front panel. It might belong inside presets or under an Advanced section. That depends on whether users immediately understand the audible result.

WHAT I THINK THE INTERNAL DSP COULD LOOK LIKE

I originally imagined around 12 internal spectral regions. After hearing how convincing a four-band version can already be, I no longer think 12 should be treated as a requirement.

It might be 4, 6, 8, 12, or 16 bands. Whatever the minimum is that produces a perceptually continuous result.

The architecture could look roughly like:

INPUT

→ MULTIBAND SPLIT

→ BAND 1 → LEVEL WEIGHT → RESONANT / DECAY CELL

→ BAND 2 → LEVEL WEIGHT → RESONANT / DECAY CELL

→ BAND 3 → LEVEL WEIGHT → RESONANT / DECAY CELL

→ ...

→ BAND N → LEVEL WEIGHT → RESONANT / DECAY CELL

→ SUM / RECONSTRUCTION

→ BODY AMOUNT

→ OUTPUT

The important part is that the bands should NOT sound like separate processors. The reconstructed result should behave like one object.

FILTER-BANK CONSIDERATIONS

I would want clean reconstruction, very low latency, no obvious crossover coloration, no phasey hollowness, no band pumping, and no obvious spectral discontinuities.

I’m not convinced hard brick-wall crossovers would even be desirable. A real physical structure does not suddenly change behavior at 500 Hz because someone drew a line there.

Broad or complementary overlapping regions may sound more natural. A constant-Q or perceptually/logarithmically spaced structure might make more sense than equal-Hz bands.

This is where somebody with much stronger DSP chops than mine could probably design something considerably more elegant than my crude prototype.

THE RESONANT CELL

I don’t think this needs a conventional reverb engine at all. I would probably try damped resonators, short feedback delays, band-limited feedback structures, or second-order resonant cells.

Something conceptually like:

band input → energy-storage element → damping → feedback / resonant persistence → band output

If a delay structure is used, I would keep it short enough that it never becomes a perceptible repeat. It is not there to create an echo. It is there to store energy temporarily.

If a feedback delay is used, the feedback gain can be derived from the desired T60:

g = 10^(-3 × Td / T60)

For a sample-by-sample resonant pole, something like:

r = 10^(-3 / (Fs × T60))

could provide the equivalent pole-radius relationship.

Obviously, whichever structure is used has to remain numerically stable across sample rates, automation, size changes, richness changes, and coupling changes.

AVOIDING THE “RESONATOR EFFECT” SOUND

There is an obvious danger here. A handful of high-Q resonators can very quickly sound like ringing, comb filtering, metal, whistles, or a tuned special effect.

That is NOT what I want.

Instrument Body should be perceptually broad and structural.

Potential approaches might include broader resonance bandwidths, multiple slightly offset modes inside a band, modest damping variation, small adjacent-band coupling, or tiny internal decorrelation.

What I would NOT want to do is solve the problem by putting a generic late reverb underneath it. That takes me straight back to the smear I’m trying to avoid.

SERIES INSERT, NOT “ANOTHER REVERB SEND”

I would want Instrument Body inserted directly after the source:

Virtual Instrument → Instrument Body → Room Reverb → Mix

Externally it behaves like a series processor. Internally it can obviously preserve the direct signal and add the generated body component.

Mathematically:

Y(t) = X(t) + R × B(t)

where:

X(t) = original source

B(t) = modeled body response

R = Richness / body amount

The reason I still think of it as a series insert is that the NEXT processor should receive the completed instrument.

I do not want the room receiving one dry piano plus some unrelated “body reverb” floating on an aux return somewhere else.

Conceptually: the body travels with the instrument. The room does not.

MEASUREMENT: WHAT I WOULD ACTUALLY DO

I would NOT call what I’m proposing a pure impulse-response measurement of the isolated body. That would be overstating it.

What I really want is:

EFFECTIVE INSTRUMENT-BODY RESPONSE UNDER CONTROLLED CLOSE-MIC CONDITIONS.

For example, with a piano:

1. Put the instrument in the deadest practical environment.

2. Place a close microphone where room contribution is minimized while still capturing a useful integrated physical response.

3. Fix the microphone position.

4. Define the instrument state: pedal up / normally damped, or pedal down / extended sympathetic condition.

5. Play a selected reference note at a repeatable level.

6. Record attack and decay.

7. Repeat the strike several times.

8. Compare or average the results.

9. Repeat at other reference notes.

Then analyze the recording through a filter bank similar to the one intended for the plugin.

For each band: measure initial response magnitude, measure decay envelope, fit the useful dB/time slope, and derive an effective T20/T30/T60 or other useful time constant.

I’m not trying to isolate string, bridge, soundboard, case, air cavity, and frame as completely independent systems. For this product idea I care more about the useful composite behavior of the real acoustic instrument.

HOW MANY NOTES WOULD ACTUALLY NEED TO BE MEASURED?

Maybe surprisingly few.

I would start with two anchor regions, perhaps approximately a low A and a high C for piano.

If that interpolates convincingly, great.

If not, use four points:

low

low-mid

upper-mid

high

For each point I want Peak(f) and Decay(f), then interpolate across the internal bands.

I would NOT begin by measuring all 88 piano notes just because it is possible. The design goal should be minimum complexity required to get the perceptual result.

If four points work, four points are better than 88. If four points fail, collect more data.

PEAK RESPONSE IS JUST AS IMPORTANT AS DECAY

One thing I don’t want to lose in all the decay discussion is that the body probably also needs a frequency-dependent level function.

Again:

Peak(f)

This is NOT just corrective EQ. It is the amount of body response generated in each region.

So internally the body model really has two main curves:

BODY LEVEL = Amplitude versus Frequency

BODY DECAY = Time versus Frequency

A particular region may have moderate body level but long persistence, while another may have high body level but short persistence.

The combination is what creates the physical impression.

PROPAGATION TIME

A real physical instrument probably has small propagation-time differences through its structure. Mechanical energy obviously does not teleport.

But for V1 I would ignore almost all of that.

If the body is storing energy for hundreds of milliseconds or a second or more, tiny structural travel-time differences are probably second- or third-order in a normal mix.

So my first version would effectively use:

Predelay ≈ 0

Any delay would exist because the resonant algorithm requires it, not because I’m trying to create an external-space cue.

WHY I THINK THIS COULD APPLY TO MORE THAN PIANO

Piano is just the most obvious example because it is physically huge, but the idea should apply to a lot of sources.

ACOUSTIC GUITAR: A DI or very dry guitar may contain plenty of string information but not enough convincing body behavior.

MANDOLIN: Same idea, but probably much faster body response, higher rollover frequency, and less stored low-frequency energy.

VIOLIN: Could add resonant wooden-body behavior to sampled or synthetic strings.

CELLO: Same family of idea, but larger and slower.

UPRIGHT BASS: Larger low-frequency persistence.

HARP: Large distributed resonant structure.

WOODEN PERCUSSION: Cajón, shells, wood blocks, certain drums, etc.

SYNTHETIC SOURCES: This would be creative rather than corrective, but there is no reason a synthetic pluck could not be “attached” to a modeled wooden body.

V1 USER INTERFACE

I would keep the front panel almost stupidly simple:

INSTRUMENT

SIZE

RICHNESS

Possibly:

COUPLING

That’s it.

INSTRUMENT selects the underlying family model: Grand Piano, Upright Piano, Acoustic Guitar, Mandolin, Violin, Cello, Upright Bass, etc.

SIZE could begin as Small / Medium / Large or use meaningful family-specific choices.

RICHNESS is basically: how much generated body response?

COUPLING, if exposed, would run Natural <-------> Extended.

I do NOT want users staring at 12 crossover frequencies, 12 decay knobs, 12 resonator Q controls, feedback matrices, damping constants, etc.

The internal model can be complicated. The UI should not be.

THE BYPASS TEST

This is probably the single most important design test.

With Instrument Body OFF, the source should still sound like a legitimate source.

With Instrument Body ON, the source should sound like the SAME instrument, but with a physical object behind it.

The desired reaction is NOT: “Oh, nice reverb.”

It is: “That sounds more like an actual instrument.”

If bypassing it suddenly makes the source feel smaller, flatter, thinner, more synthetic, or more obviously sampled, then the processor is doing something useful.

If enabling it produces obvious wash, room size, predelay, or a noticeable external tail, then the processor is probably doing too much.

WHAT I ABSOLUTELY WOULD NOT MARKET THIS AS

This is not “crap in, gold out.”

I would not pitch it as:

make cheap piano sound expensive

make bad samples realistic

fix poor recordings

magic acoustic realism

instant warmth

instant analog

instant 3D

A poor source remains poor. A badly played source remains badly played. A badly recorded source remains badly recorded. A bad virtual instrument remains a bad virtual instrument.

Instrument Body would solve one specific problem: missing or insufficient physical instrument-body behavior.

That is all.

SPATIAL RADIATION — PROBABLY V2

There is another whole layer to this concept that I think is real but that I would intentionally leave out of V1.

Large instruments are not point sources. A piano is the obvious example. The low strings and high strings occupy physically different parts of the instrument. The sound changes depending on whether you are to the left, to the right, in front, behind, or near the player position.

That suggests a future model like:

Pan(f)

or more accurately:

Radiation(f, listener position)

For a grand piano, the body-generated component of low notes might lean one way and high notes the other.

Perspective could matter:

Player

Audience

Front

Rear

The spectral response could change with direction too.

A violin would need far less spatial separation because the physical body is much smaller. A grand piano could use considerably more.

But I would absolutely NOT put this in the first version.

First prove Peak(f) + Decay(f) + Size + Richness actually solve the body problem. Then add radiation later.

RELATED TECHNOLOGY

I know there are technologies that overlap parts of this.

Physical-modeling/resonator processors can feed external signals into modeled objects such as plates, strings, beams, membranes, etc.

Modal-filter structures can provide multiple resonant bands, independent frequency, independent decay, and independent gain.

There is also published work around modal and hybrid modeling of instrument bodies, including approaches where lower frequencies are modeled as discrete resonances and upper behavior is handled statistically or with reverberant structures.

There have also been instrument-specific attempts at modeling acoustic body behavior.

So I am NOT claiming “nobody has ever thought about resonant instrument modeling.” That would be ridiculous.

What I personally have NOT been able to find is a commercial plugin presented specifically around THIS complete workflow:

general-purpose

multi-instrument

series insert

minimal controls

placed before environmental reverb

explicitly intended to restore or supply instrument-body behavior rather than act primarily as room simulation, creative resonator, sound-design effect, or complete instrument synthesizer

That statement means exactly what it says:

I haven’t found one.

It is not a claim that none exists.

WHAT I WOULD WANT V1 TO PROVE

Take a decent piano VST that has good source material but feels physically small. Insert Instrument Body.

I would want:

The notes still sound like the same samples.

The attack remains intact.

The hammer remains intact.

Pitch remains intact.

No obvious room appears.

No smeared generic late tail appears.

The keyboard becomes more coherent across registers.

The low end acquires believable physical persistence.

The upper end remains faster and lighter.

The instrument acquires more apparent mass.

The body response feels connected to the note.

The complete thing feels more like one physical object.

Then bypass the plugin.

If the piano suddenly collapses in apparent physical size: good.

Then repeat the same test with acoustic guitar, mandolin, violin, cello, and upright bass.

If one underlying DSP architecture can handle those by changing Peak(f), Decay(f), Size, and perhaps Coupling, then I think the general concept is validated.

CPU / LATENCY

I would want this to be usable live.

So:

no required lookahead

no giant convolution engine

no enormous FIR filters unless absolutely necessary

no offline analysis during playback

no huge latency

A 4–12 band resonator bank should not inherently be computationally outrageous.

The preset generation and measurement process can be sophisticated. Runtime should be simple.

PARAMETER SMOOTHING AND STABILITY

Any resonant system has obvious implementation risks.

If the user moves Size, Richness, or Coupling, the DSP cannot suddenly jump feedback coefficients, pole radii, resonance frequencies, or crossover values.

Everything needs appropriate smoothing, otherwise you get clicks, bursts, ringing, pitch shifts, or instability.

If cross-band coupling is used, the total feedback system obviously has to remain stable.

The plugin should never blow up numerically because somebody turned “Large” to “Very Large.”

POSSIBLE COUPLING IMPLEMENTATION

The simplest first version may not require actual cross-band energy transfer.

Coupling could simply interpolate between two calibrated decay families:

Natural Decay(f)

Extended Decay(f)

That would be cheap and predictable.

A more physical later model could allow neighboring regions to exchange a small amount of energy:

Band 5 weakly feeds Band 4 and Band 6

That would make the system act a little less like independent filters and a little more like one coupled object.

But again, I would NOT add that unless it audibly helps.

THE PHILOSOPHY I WOULD USE TO BUILD IT

The real physics of an acoustic instrument are insanely complicated.

A serious physical model could potentially include string coupling, bridge impedance, soundboard modes, anisotropic material behavior, bracing, cavity modes, radiation impedance, directionality, damper state, lid state, nonlinearity, etc.

I don’t think this plugin needs all of that.

I think the useful question is:

What is the smallest set of behaviors that makes the ear believe “There is a physical instrument behind that note”?

My current guess is that the first-order set is:

Peak(f)

Decay(f)

low-frequency rollover

Size

Coupling

Richness

Maybe that is enough. Maybe it is not.

But my crude prototypes suggest the idea deserves testing before anybody builds a full finite-element piano simulation.

THE THING I FIND MOST INTERESTING

The more I worked on this, the more I realized I had originally been asking reverb to solve the wrong problem.

I thought:

“This piano needs more acoustic space.”

But what I was actually hearing was:

“This piano needs more piano.”

Once I separated those concepts, the signal chain became obvious:

EXCITATION → PHYSICAL BODY → ENVIRONMENT

The body should go with the instrument.

The room should come afterward.

That is really the whole concept.

If anyone here works in physical modeling, modal synthesis, resonator design, filter-bank DSP, acoustic measurement, or plugin development, I’d be very interested in where you think this idea breaks technically.

In particular:

1. Is a small filter bank, maybe 6–12 bands, enough to create perceptually continuous body behavior?

2. Would you implement each band with a damped resonator, short feedback delay, modal bank, or something else?

3. Do broad overlapping bands make more sense here than strict complementary crossover bands?

4. Should the apparent low-frequency decay rollover be modeled explicitly as part of Decay(f)?

5. How much of body timing might scale usefully with physical instrument size?

6. Would cross-band coupling improve realism or mostly create unnecessary complexity?

7. Is there already a commercial plugin that packages this exact concept and I simply haven’t found it?

8. Could the useful front panel really be as simple as Instrument / Size / Richness / Coupling while everything else stays under the hood?

I’m particularly interested in criticism of the core concept, not just additional features.

If the physics are more complicated but the simplified model produces the perceptual result, I would consider that a success.

The objective is not to perfectly simulate every vibrating part of a piano.

The objective is to make a good electronic source stop sounding like it forgot to bring the physical instrument with it.

That is what I mean by:

INSTRUMENT BODY.

The effect is for the instrument.

Not the environment.

Hi everyone! I’m a statistics senior hoping to transition into signal processing after graduation, and I’d appreciate advice on building relevant skills, projects, and a portfolio for entry-level roles.

I've had previous exposure to signal processing through a signal reconstruction research project involving simulated RF data and an internship with a neuroimaging company, where I worked with fNIRS data. I can’t include either project in a public portfolio (for reasons beyond my control), and I also didn’t fully understand the concepts behind them at the time. For that reason, I’d like to build my own personal projects from the ground up.

I became seriously interested in DSP after an internship mentor explained Fourier transforms and wavelets to me. I was fascinated by the combination of mathematical rigor, computation, and messy real-world data. In particular, I’m interested in reconstructing signals, recovering information from noisy/lossy measurements, modeling noise and uncertainty, and developing adaptive or predictive systems.

My main challenges are:

• I won’t be able to take Signals and Systems or Introductory DSP before graduating.
• I’m unsure which DSP concepts I should prioritize for self-study.
• I don't know which statistical skills transfer most directly to DSP.
• I need to develop portfolio projects relatively quickly while still finishing my degree.
• I’m still deciding which application area to focus on. I'm considering communications, audio, or radar.

I’d also appreciate recommendations for:

1. A practical learning path for someone without formal EE coursework.
2. Portfolio projects that would demonstrate genuine DSP understanding to employers.
3. The minimum mathematical and programming foundation expected for entry-level DSP roles.
4. DSP-adjacent jobs that might be realistic for a statistics graduate with strong portfolio evidence.

I plan to attend graduate school eventually, but I’d prefer to work in the field first so I can make an informed decision about specialization. For now, I’m primarily interested in becoming employable with a bachelor’s degree.

Thanks in advance!

I'm building a drum practice-pad training app and I'm trying to design the hit detector from scratch rather than relying on a generic onset-detection library.

The goal is to detect individual practice-pad strokes in real time with millisecond-level timing, while rejecting unrelated sounds such as speech, claps, keyboard/desk taps, doors, etc.

Current setup:

• C++ on Apple devices
• Core Audio input
• 48 kHz sample rate
• 256-frame hardware buffers
• Accelerate/vDSP for DSP
• Low CPU usage is important
• Calibration to the user's specific pad is acceptable, although ideally it wouldn't be required

I'm intentionally trying to stay with classical DSP for now rather than using a neural network, because I want to have full control over the detector and mostly because i don't have tons of training data.

What approach would you use for this?

I'm interested specifically in identifying the acoustic "fingerprint" of a practice-pad hit, rather than simply detecting transients. For example, I've been considering things like normalized cross-correlation, spectral/time-frequency fingerprints, envelope shape, matched filtering, or combinations of these.

The important requirements are:

• Very low false-positive rate
• Reliable detection of soft and hard strokes
• Tolerance to slightly different striking positions
• Accurate hit timestamps
• Real-time operation on an iPhone/Mac

I have zero experience on DSP and audio engineering so i need the help of a professional.

After two years of development, I am finally releasing cutcutcodec, a fully hand-coded Python library for audio and video signal processing. Unlike moviepy, which is based on the concept of clips, CutCutCodec is based on the concepts of media streams and editing graphs, which are less restrictive, but slightly more verbose.

Here is the project documentation: https://cutcutcodec.readthedocs.io/latest/
A few examples: https://cutcutcodec.readthedocs.io/latest/getting_started/tutorial.html

It is aimed at developers and the signal processing / machine learning community. I/O relies on PyAV (FFmpeg), computation on PyTorch (CPU/GPU), with some parts in C.
Here are a few kernel functions that give a bit of an idea of what’s going on:

• sympy_to_torch -> Compile a sympy epression into a differenciable vectorize torch code
• grah_to_ast, graph_to_json, graph_to_tree -> multiple representations of the same graph
• opti.cuda, opti.parallel -> auto GPU/CPU, cache and thread optimizations
• vmaf, ssim, psnr -> C implementation and torch differenciable metrics
• nn.models.enhancement -> a basic example of ML integration
• Colorspace -> an exhaustive symbolic representation and management of the International Telecommunication Union's color-space specifications and implementations. (see the doc)
• test -> more than 453 unitary tests

Let see a little basic example:

import cutcutcodec
container = cutcutcodec.read("input_video.mp4")  # open the file
stream = (
    container.out_select("video")[0]  # first video stream
    .apply_video_subclip(0, 10)  # keep the 10 first seconds
    .apply_video_equation("r0", "g0", ".5*b0*sin(2*pi*0.5*t)+.5")  # blink blue
)
streams_settings = [{"encodec": "libx264", "rate": 30, "shape": (480, 720)}]  # optional
cutcutcodec.write([stream], "output_video.mp4", streams_settings=streams_settings)

There is also more complexe action like Winer audio denoising (full example):

denoised_container = (noise_container | noisy_container).apply_audio_wiener(level=0.98, band=20.0)denoised_container = (noise_container | noisy_container).apply_audio_wiener(level=0.98, band=20.0)

If you have any feedback for me, I'd love to hear it!
source code: https://framagit.org/robinechuca/cutcutcodec

Hi all.

I am trying to implement a RF repeater with digital filtering. The IF BW is 1 MHz, and the channel can be arbitrarily placed within this 1 MHz BW. The channel needs to have gain applied and bandpass filtered to remove unwanted channels from being amplified.

The channel BW can be arbitrarily chosen, minimum 25 kHz, to full 1 MHz bandwidth. The stopband needs to be fairly close, e.g. for the 25 kHz channel, the stopband will start at 50 kHz (at 60/80 dB att?). This makes me think it would be easier to downsample to a lower sample rate depending on the channel bandwidth before doing the channel filtering.

As im not a DSP-guru i would like to get some feedback on if this is the way to go.

My inital thoughts was doing it some like this:

ADC -> NCO/downconvert -> decimation filter -> Downsample -> LPF(Channel filter) -> Upsample -> interpolation filter -> NCO/upconvert -> DAC

I believe this requires the decimation and interpolation filters to run at the full sample rate, which depending on the specifications would require a lot of computation/no of taps.

Also, the application might be multiple channels in the future. That is also taken into consideration when i came up with this architecture. So basically everything between the ADC and DAC needs to be multiplied the number of channels that needs to be supported?

Is this how something like this would be done? Or are there better ways to reduce computational load? I have read about polyphase fir filters for down/up-sampling, but im not sure if that will help me in this case.

Hope someone will chime in.

Hi everyone,

I'm a 23-year-old Electronics & Telecommunication engineer from India, currently working in hardware testing at an engineering services company for around 1 year. I'm trying to figure out what career direction actually suits me.

In college, I enjoyed Signals & Systems, Digital Communication, Digital Electronics and mathematics, and I've always been interested in how 4G/5G/6G and wireless communication work.

I'm currently exploring:

DSP / Signal Processing

Communication Systems

Wireless / 5G PHY / Baseband

RAN

SDR / RF

Telecom R&D

Radar / Satellite Communication

The problem is that these all sound related, but I don't really understand what the actual day-to-day work is like, or whether I'd enjoy it.

A little about me:

I don't enjoy DSA/competitive programming or generic software development.

I don't mind programming when it's used for engineering, simulation or problem-solving.

I like mathematics and understanding how systems work.

I don't want a heavily lab/field/hardware-testing job.

I'm currently learning/considering MATLAB and Python.

My current testing work feels repetitive, and I don't feel I'm learning much.

For people actually working in these fields:

1. What does your typical day/week look like?

2. How much of your work is theory/mathematics vs coding, debugging, meetings and documentation?

3. What languages/tools do you actually use (MATLAB, Python, C/C++, etc.)?

4. Do you need DSA/LeetCode for these jobs?

5. What do you enjoy and dislike most about the work?

6. How much hardware/lab/field work is involved?

7. How different are DSP, 5G PHY/Baseband, RAN, SDR and RF roles in practice?

8. Is an MS usually necessary for algorithm/R&D roles, or can someone with a bachelor's degree and good projects get in?

9. If you were starting again with an ECE degree and ~1 year of unrelated experience, what would you learn/build to figure out whether this field suits you?

I'm not asking which field is "best." I mainly want to understand what the actual work feels like so I can figure out what I personally enjoy.

I'd especially appreciate answers from people who currently work in these fields or have several years of experience.

Thanks!

Hi everyone,

I’ve recently developed a strong interest in audio DSP and I’m trying to figure out what a realistic path into the field would look like.

I recently completed a degree in Digital Audio Arts, where I gained a solid foundation in audio and some practical experience. I’ve also gained experience working in the commercial AV industry, and I’m currently enrolled in a software development program.

I’m really interested in combining these two areas — audio and software development — and eventually working in audio DSP or audio programming.

I’ve really enjoyed the programming I’ve done so far, and I’m slightly intimidated by the math involved with DSP. I'm currently doing a Math for technologists course and will also have a higher level math course after this. My main concern is my academic background. From what I’ve seen, a lot of people working in DSP seem to come from EE, computer engineering, or related engineering backgrounds. As well as it seems a lot of DSP is learned at the master/phd level.

I’m wondering whether employers would be hesitant about someone like me because my education and experience don't follow the typical path into DSP. I’m willing to put a significant amount of time into learning the necessary math, DSP concepts, C/C++, embedded systems, etc., and building projects to demonstrate my skills.

I realize this is a fairly niche field, so I’m curious to hear from people actually working in audio DSP:

• What would be a reasonable path into audio DSP/audio programming for someone with my background?
• How important is an EE/engineering degree for getting an entry-level DSP role?
• What technical skills should I prioritize?
• Would personal DSP projects/portfolio work meaningfully help compensate for not having an EE background?
• Are there particular types of roles or companies I should target initially?

I’m essentially trying to figure out whether this is a realistic career transition and, if so, what I should focus on over the next few years.

One of my biggest goals next summer is getting a relevant internship. What role would make the most sense for my career goals?

Thanks!

For a couple months now an unknown sound has been bothering me making my ears ring at home and in the car. The attached photo shows a band at around 3kHz and two more at 5-6kHz. I believe these are the offending tones. I want to build a portable synchronized microphone array to locate persistent narrowband acoustic components around 3 kHz and 5–6 kHz. I want to distinguish direct arrivals from indoor reflections and estimate direction of arrival while moving the array between measurement positions. I am not a professional at this so would like to get some crowdsourced ideas please, and thank you.

Hey everyone! I’m sharing the first alpha of Ratio9, a synth I’ve been building for sound design.

Its main features are:

• Three wavetable oscillators, each with two warp controls.
• Mod Flow routing for FM and other oscillator-to-oscillator modulation.
• Six editable LFOs with custom shapes and flexible modulation routing.
• Unison, phase, random phase and stereo controls.
• A sub oscillator, sampler, filters and multiband effects.
• 250 factory wavetables and 45 presets, covering basses, leads, pads, chords, keys, plucks, sequences and more.

It’s available for Apple silicon M-series Macs as a Standalone app, VST3 and Audio Unit .component.

Download Ratio9 Alpha 1.0.0:
https://github.com/Ratio9FM/ratio9-downloads/releases/tag/v1.0.0

Each format includes the preset bank. Installation instructions and known issues are on the download page. This is an early alpha and isn’t Apple-notarized yet, so please read those instructions before installing.

Ratio9 is currently closed source; GitHub is hosting the downloads and documentation.

I’d love feedback on the sound, interface and workflow—especially anything that feels confusing or gets in the way of making a patch. If you find a bug, please include your Mac/macOS version, format or DAW, preset and steps to reproduce it.

Thanks to anyone who gives it a try!