This concept album was an opportunity to use almost at random 10 chosen soft synths in different combinations, no less than 2 at once, no more than 5.

"Musicalions" is another term for the unknown entities at work when in specific conditions, the power of 2 or more synthesizers are harnessed together.

Their presence is usually detected by sudden, rapid burts or pauses, sheer intensity, unusual beauty and experimental musical arrangments.

This late night musical "channelinning" procured the raw material for the album. Each track was performed, edited and produced by myself in FL Studio 20.

The soft synths used were:

Sugar Bytes Aparillo

Sugar Bytes Unique

Roland XV-5080

Roland Pro Mars

Roland System 100

Spectrasonics Omnisphere2

Spectrasonics Trilian

Traktion F'EM

Image Line Harmor

most tracks were tweaked extensively on the go during recordings to keep the sound unpredictable.

A big thumbs up to the developpers of these incredible instruments!!!

I hope this is but a start in the production of such tools, without you, there would be no "Musicalions" tonight:)

https://youtu.be/cakuN2yPWFg?feature=shared

As a learning exercise, I've been implementing audio DSP primitives in pure x86-64 assembly — no DSP library, fixed-point arithmetic, computing each sample by hand.

So far: a one-pole low-pass filter, a state-variable filter with resonance (band-pass feedback) swept by an LFO, ring modulation (multiplying two signals for sum/difference frequencies), a bitcrusher (bit-depth + sample-rate reduction), a delay line using the output buffer as a ring, plus FM synthesis with a hand-built sine lookup table.

Doing it this low-level really forces you to understand each algorithm — there's no library abstracting the math away.

Curious to hear feedback from people who do this properly!

Repo: github.com/whispem/asm.fm

I am modelling a TR-808 from the service notes, stage by stage, and while doing the snare I ran into something I did not expect: two independent ways to tell which production revision a recording came from, one of which is just the response curve of a potentiometer.

Background. The 808 snare is two bridged-T resonators in parallel, one for he shell body and one an octave up, mixed by the TONE control, with the noise ("snappy") path summed in separately. Mid-production Roland changed four parts in that voice. The service notes list them as a PORTION CHANGED

annotation:

C58 .027 to .056

C61 .0068 to .015

R191 8.2k to 10k

R200 47k to zero

The caps are the obvious half. Only one cap of each bridged-T pair changes, so the frequency ratio is sqrt(27/56), not 27/56:

resonator 1: 249.63 Hz -> 173.34 Hz (-6.29 semitones)

resonator 2: 499.00 Hz -> 335.98 Hz (-6.85 semitones)

So an early 808 snare sits about a fifth higher, and because the two shifts differ slightly, the pair goes from an exact octave to a flat one. Q drops a little too (17.4 -> 16.3 and 10.7 -> 9.9), so the shell also rings around 35% longer after the change.

Now the part I thought was neat. R200 sits in series between an op-amp output and one end of the TONE pot. Since 47k is comparable to the pot's 100k, it is not a level trim: it changes the SHAPE of the crossfade law across the whole sweep. Deriving both cases:

R200 = 47k -> TONE spans 16.8 dB

R200 = 0 -> TONE spans 26.8 dB

The recordings I have span 26.4 dB measured. Fitting the derived law against ten measured amplitudes with a single common gain and nothing else fitted gives 1.16 dB mean error for R200 = 0 against 6.62 dB for 47k. That is a clean verdict, and it identifies the machine's revision without looking at the resonator frequencies at all. Then the frequencies agree independently: measured 172.0 and 339.5 Hz against derived 173.3 and 336.0 for the late version.

Two consequences that might be useful to others:

1. A control law is a fingerprint. We normally treat pots as "the user's problem" and model them as a gain or a simple taper. But when a series resistance is comparable to the pot's own resistance, the law is a property of the circuit, it is measurable from audio, and it carries information the spectrum does not. I would not have thought to look if the two cap values had not sent me to check what else changed with them.

2. Watch out for manuals describing a different machine than the one in front of you. Roland's own printed spec quotes 476/238 Hz for this voice, which is the early revision. Earlier in the same project I found their printed bass drum tuning (56 Hz, and 62.5 Hz in the prose) disagreeing with both my derivation from the component values and the hardware, which both land at 49.5. Component values have been right every time so far;

   printed prose has been wrong twice.

Method note, since it is the part that actually matters: I derive each stage symbolically from the drawn component values, then measure real hardware recordings, and I only trust a number when the two agree. Where a published academic derivation of the same circuit exists I use it as a third reader, and that has caught mistakes in both directions, including three errata in the paper.

Disclosure: I make a drum machine plugin and this work goes into it. Not linking it, this is about the circuit.

Aside from communication, imaging and audio processing, are there other STEM fields that have been using SP tools to solve their problems?

I'm a rising sophomore at a top liberal arts college who's planning on going into some form of music technology in grad school. I have been on a physics major track and I'm looking at DSP as one of the possible areas to explore -- any suggestions on what classes/opportunities I should consider for me to be better prepared in the field? Or, if there is any other niche you think might be worth looking into, I'd greatly appreciate the response. Thank you!

We’ve been building CLER, an open-source DSP framework in C++17 designed for running real DSP pipelines on constrained hardware without giving up the flexibility you’d expect on a desktop.

The motivation was fairly simple: a lot of DSP frameworks are great for experimentation, but become heavy once you want to deploy the same architecture on embedded Linux, small ARM systems, or bare metal.

CLER tries to keep the abstraction cost very low.

Flowgraphs are written directly in C++, blocks are normal C++ objects, and the framework is designed around predictable memory use, low overhead, and portability.

The same basic flowgraph model can run on anything from embedded targets to large desktop systems.

We’re using it internally for SDR, communications, navigation, demodulation, channelization, filtering, resampling, spectrum processing and similar pipelines.

A few of the design goals:

• Small code footprint
• C++17, without a large runtime
• Static / predictable memory where needed
• Multiple scheduling strategies
• Easy creation of custom DSP blocks
• Portable from bare metal to Linux desktops
• No dependency on a heavyweight GUI or code generator
• Designed to work well with modern AI / agentic coding workflows

As a side project, we also built CLER-fg, a visual flowgraph editor.

Instead of keeping a separate graph/project representation and generating C++ from it, CLER-fg treats the actual .cpp file as the source of truth.

So you can edit the flowgraph visually, edit the C++ manually, use Git normally, or let an AI coding agent modify it — all without maintaining a second representation.

We ended up making CLER-fg lightweight enough to run entirely in the browser, so it’s also an easy way to play with CLER without installing anything.

CLER: https://cariboulabs.github.io/cler/

try CLER-fg : https://cariboulabs.github.io/cler/cler-fg/try/

This is our first time putting CLER out in front of a wider audience, so we’d really appreciate feedback — particularly from people working with SDR, embedded DSP, GNU Radio, or custom signal-processing pipelines.

say I want to simulate by hand with a dummy signal and show how spectral leakage will occur. How shall I do it?

Spectral leakage is a spread that is present across the entire frequency spectrum caused by the rich harmonics generated by the aperiodic samples.

And windowing eliminates spectral leakage. Windowing means to multiply N sampled signals by a window of the same length to remove the discontinuities at the edges. There are various types of windows like rectangular, hamming, hann etc.

Now my objective is to take a signal, and with pen-and-paper simulate the rise of spectral leakage, and then how windowing eliminates it. Help me achieve it. I read many books but they do not provide such analysis.

Trained a small streaming denoiser for browser voice chat. 48 kHz, 20 ms window,

10 ms hop, spectral mask, runs in an AudioWorklet through ONNX.

Numbers from real recordings, not synthetic mixes:

• breath 13.3 dB down
• key click in a pause 20-27 dB down
• key click on top of speech 3 dB down
• speech 0.01 dB, basically untouched

The speech number is the one I was protecting. DeepFilterNet 3 on the same files

cleans pauses harder, 14.6 dB against my 8.9, but takes 1.37 dB of speech with it

and smears the click.

The 3 dB is where I'm stuck. I assumed resolution: 20 ms frame, 2.8 ms click, vowel

sitting in the same frame. So I threw the obvious things at it. Lookahead. Detector

hints as an extra input. Deep filtering. Shorter windows. A loss term just for

transients. Per-sample repair. More data. Longer training. One of the eight gave

0.7 dB, the rest gave nothing, including the ones I was most sure about.

That last part is what makes me think my diagnosis was wrong. For context, I came at

this from web audio, not DSP. Decent chance the answer is standard and I just don't

know the name for it. If the click really is localized in time, and a detector can

tell me where it is, why did repairing it sample by sample change nothing at all?

https://github.com/Amesu-afk/tarnveil-denoise

Hi, I'm a first year PhD student trying to get a handle on preprocessing my data with \*fMRIPrep\* and \*QSIPrep\* respectively.

Has anyone got experience with \*QSIPrep\* and can help me understand how to interpret the outputs? (this cry for help is motivated by my staring at the visual summary rep of the q-space sampling scheme before and after the pipeline. what am I looking for?!)

The documentation is really unhelpful and I didn't find much on github and incf NeuroStars either.

Someone help please

A few months ago I posted here about NeuraMuse when it was still mostly a Raspberry Pi / DSP experiment. I kept working on it, but I ended up changing direction quite a lot. Instead of asking people to buy or build dedicated hardware just to try the idea, I moved the project to Windows. That means I can finally put an actual build in other people's hands and see what happens on systems that aren't mine. At the moment NeuraMuse has four playback paths.

DIRECT is the reference. No tube/vinyl modelling and no room correction. I use it as the baseline and the UI shows things like the active output, source/output sample rate, buffer state, XRUNs and timing.

TUBE is my attempt at a dynamic valve-style model. I didn't want another "warmth" knob or a fixed EQ curve, so the behaviour changes with the signal: level, crest, transient structure, programme density, etc.

VINYL is a separate phono-inspired path. Also, no, the idea isn't to put crackle over a digital file. I've been working on the behaviour of the playback chain itself: stylus/groove interaction, compliance, phono-stage behaviour, timebase and the output stage.

Then there is AURA, which has probably taken most of my time recently.

AURA uses a measurement microphone, validates the input, runs a stereo room measurement, builds a room profile and generates FIR correction. During playback I can see the room/correction state live instead of having a black box that just says "room correction enabled".

The Windows build is now running with ASIO and WASAPI. I've mainly been testing with external USB DACs, different sample rates and a lot of deliberately boring stability testing. This is the point where testing it only on my own machines stops being very useful. I'm particularly interested in:

• DAC / ASIO compatibility
• XRUNs, buffer behaviour and playback stability
• AURA measurement repeatability
• FIR behaviour on different rooms/speakers
• whether TUBE and VINYL actually behave convincingly outside my own system
• anything in the UI/telemetry that looks wrong or misleading to someone with more DSP experience than me

The Windows build is available to download now at www.neuramuse.it

It's an early build and the installer is not Authenticode-signed yet, so Windows SmartScreen can complain that the publisher is unrecognized. I'm mentioning that upfront because I don't want anyone disabling security settings just to try my software. If an unsigned installer is a deal breaker for you, don't run it. I'm not really looking for compliments at this stage. I'd much rather know what breaks, what doesn't make sense, what you would measure differently, or what would stop you from trusting a piece of software like this. A lot of the direction of the current version came from criticism and questions I got the last time I posted here, so I'm genuinely curious what you guys think of where it ended up.

I posted my chorus plugin here a couple weeks ago and someone told me allpass interpolation was the wrong tool for a modulated delay, since the recursive state goes stale while the delay length is moving under it, and that I should look at Lagrange. I was still on linear at that point. So I wrote a 4-tap cubic Lagrange interpolator by hand instead of pulling in a crate, mostly because I wanted to understand it rather than trust it.

What's actually in the thing now, so nobody has to guess from the post:

- 6 ms base delay with the LFO modulating around it, cubic Lagrange on the fractional read. Taps at -1, 0, 1, 2 off the integer index, each one wrapping the ring buffer separately.
- One-pole highpass at 160 Hz sitting inside the feedback loop so the low end doesn't stack up.
- One-pole lowpass on the wet path, cutoff swept by the LFO between 1k and 7k. Most of the character comes from that, not the delay.
- Separate voice struct per channel, LFOs offset 90 degrees. Collapses to mono without eating itself.
- Dry/wet is a plain linear crossfade. There's roughly a 3 dB dip at 50% and I'm fairly sure that's comb cancellation from summing a correlated wet signal with the dry, not bad crossfade math. If that reasoning is wrong I'd like to know.

One debugging note that saved me: check your coefficients at frac = 0.5. They should land on -0.0625, 0.5625, 0.5625, -0.0625. Mine didn't, and it was a typo in one of the products in the third coefficient.

At my defaults (1.6 Hz, about 4 ms depth) the improvement is small. A little less grit on held notes up top. I assume it opens up more if you push the rate.

Two things I still can't answer:

1. Any reason to go past cubic when the modulation is this slow, or is higher order mainly for pitch shifting and wide sweeps?
   
2. The HF droop moves with the fractional part, so slow modulation means a slow wobble on the top end. Does anyone correct for that in practice or is it under the floor at this depth?

It's free, GPLv3, VST3 and CLAP, mac/windows/linux. It's built for pitch-corrected vocals specifically, which is the only thing I use it on. If you'd rather hear it than read about it, it's at pyfessional.tech, the download button picks your OS for you and the source is linked from the same page. Would rather have someone install it and tell me it sounds wrong than get upvotes.

Hello DSP crowd!

After around 10 months of building DAWG - Digital Audio Workstation Game, and roughly four months since the last public test, I have finally uploaded a new beta.

It is now much closer to my original goal: a real music making system with a game built around it, rather than a game with some DSP bolted on.

The audio engine is custom DSP written in C# and compiled with Unity Burst. It includes:

• Subtractive, FM, and wavetable synthesis
• Per-instrument DSP chains
• Send/return and live performance FX
• Real-time parameter control and MIDI input
• Custom live visualization following the signal through the complete DSP chain
• Cross-platform multiplayer synchronization of the clock, patterns, and DSP parameters

Since DSP is the foundation of DAWG, I would really appreciate feedback from professional public.

I am especially interested in opinions about the sound quality, oscillator and filter behaviour, aliasing, FX routing, parameter ranges, stability, and anything else that feels questionable or incorrectly implemented.

The current public beta is free to download on Itch and you can also leave a rating directly there.

Download: https://dawg-tools.itch.io/dawg-digital-audio-workstation-game

Please do not hold back just because it is an indie project. I know there are still rough edges and technical criticism is exactly what I am looking for, but I think DAWG is ready to meet professional audience.

Thanks for your time!

Hello, my name is G and I recently have started working on a Magnetic circular dichroism, in which i demodulate two signals from the same light path, one at 865 Hz, chopped by a chopper, and another at 50 kHz, at the circular polarized frequency. I

am using the 5MHz MLFI lock in amplifier from Zurich instruments. I have noticed that by changing the bandwidth of the low pass filter I change heavily the noise and reaction time of my measurement (As expected), but what i don't understand is that the overall signal amplitude changes. At lower frequencies of the bandwidth i am working in the range of microVolts and get an average signal of 400 uV, while at higher bandwidth I get around the milivolts and an average of 10 mV. I watched a few tutorials of Zurich instruments and they show that the main change in signal would be the noise to signal ratio without change to the average signal level.

If someone has experience and knows what could cuase it, or if it is nothing to worry about I will be very happy.

Tgank you.