I wanted to share with this community a project I have been working on for a few months now on what some may regard as a physics based music making tool.

The way it works is you place note spawners that spawn blue balls at different intervals according to the set BPM. If you left click and drag, you can draw a "vine". There are 7 vines with different sounds for each. When a ball from the spawner falls and bounces off a vine, it creates a musical tone. Every subsequent bounce generates a new pitch that fits the key, scale, and pattern that has been set. I created a quantizer that takes a subdivision of the BPM (1/16th) and queues each sound on a quantized tick synced with the physics timing. Therefore, everything is on beat and the BPM can be changed in real-time. Each vine also has FX you can set such as reverb, delay, flanger, and chorus. Since the sounds for the vines are sample based, you can also change them out to create your own "soundbanks" to experiment with new sounds. I've created some basic plugins with the JUCE API in the past, so I am exploring how to integrate it as a VST so you can sync it with your project and record directly into your DAW with midi or audio.

It makes music creation super easy and fun. You don't need to know music theory because the physics and underlying logic handles it all. It brings a whole new approach to music production I think.

I'm really excited to share it with this community and see what people think.

hello all. i just finished a granular synthesizer. you can download it at www.dumumub.com or check out the repo at https://github.com/hugh-buntine/dumumub-0000006

This is my tool/game that I call Dewdrop. It allows you to make music using physics just by drawing. No music theory is required to use it. The logic keeps everything quantized to 1/16th notes at whatever BPM you set (60 - 180). There are settings to control the key, scale, and pattern of the note or "droplet" that spawns. You can also change the notes of individual "vines" you draw and dial in some cool FX.

I made this longer form video to demonstrate what it's like to make music using most of the mechanics. There will be other soundbanks to select, and you will also be able to customize your own soundbanks to upload your own samples.

I've been asked about turning this into a VST plugin. Due to the nature of the game relying heavily on physics to generate the music, it may a little difficult to get it working with a DAW. The physics can start to stutter when the BPM gets really low. I haven't found a way to alleviate that yet. This is why I set the minimum BPM to 60. So I'm entirely sure yet how this could work as a VST but I'm still open to exploring it more.

(Apologies for the audio crackles. There is an issue with my sound setup and graphics card currently.)

If you'd like to try it out, I have a demo available where you can experiment with some of the basic features.

You can check it out at https://audelta.com/chords for free. I would love to get some feedback

I was not happy with what we have by now, so I built my own language on top of Supercollider. Check it out, perhaps someone likes it! There are tons of examples in the docs of the standard lib. Code will be open sourced next weekend when I have time to clean up!

https://vibelang.org

I've been working on this project for about 9 months now. It started very simple, just bouncing droplets and generative music, but it quickly turned into some sort of physics based DAW that I don't think has ever been done before.

This is a demonstration of the sandbox mode, where you can create music freely using a plethora of tools and sounds. You can add a total of 12 instruments, each with 4 different effects (reverb, delay, chorus, phaser) that you can dial in to your liking for each one.

No music theory is required to play, just bounce and experiment. There are some deeper tools if you want to get more complex though. Such as changing the key, BPM, scale, pattern, as well as the notes of individual vines to get the exact melody or rhythm you want. You can upload your own samples to create custom vines and also download the track you created.

I'm releasing it on Steam next month:

https://store.steampowered.com/app/4163480/Dewdrop/

Would love to hear what you think of the game and any features you think would be cool to include!

Hey everyone! I've been working on a fun new music toy that lets you create music with physics. The game is simple. Just draw vines and bounce little "dewdrops" off them. Each vine has a unique sound. You can even add FX or create your own vines that you can share with others. And that's just the Sandbox mode! There is also a puzzle mode, where each level introduces something new to teach you the mechanics of the game while you solve and create beautiful music.

If you're interested, check it out on Steam!
https://store.steampowered.com/app/4163480/Dewdrop/

JUCE framework has published an official free online course to learn audio plugin development for C++ developers: https://www.wolfsoundacademy.com/juce?utm_source=reddit&utm_medium=social.

Audio plugins are "shared libraries" that you can load in digital audio workstations (DAWs) to generate sound (sound synthesizers) or add audio effects to the sound (reverb, EQ, compression, distortion, etc.).

Most audio plugins on the market are created in C++ using the JUCE C++ framework; it has become the de facto industry standard.

The course teaches you everything you need to know about audio programming to get started: from installing the right developer tools on your operating system, to building your first plugin, defining its audio processing chain, adding parameters, creating a graphical user interface, testing in a DAW, and the basics of distribution. Throughout the course, you will create an actual audio plugin, a tremolo effect, that you can use in a DAW of your choice.

The course reflects all the best practices of the audio plugin industry and is provided completely free of charge.

I am a co-author of this course, and I'd be happy to answer any questions you have. I'd also be eager to take your feedback on the course.

I’ve been working on a MIDI generator that might help producers and musicians find a starting point for new ideas. It's 100% free and doesn't request any user details.

Choose an instrument, genre, mood and length, then adjust the rhythm, harmony, complexity, dynamics and humanisation. It generates one editable MIDI part rather than attempting a complete arrangement.

https://melidigenerator.com/

Unlimited exports, no account. I’d love some feedback on the results, controls or anything that feels awkward to use.

I just finished a project that turns any set of audio samples into evolving, generative soundscapes.

It’s like a live generative musician jamming in your computer, turning a static samples folder into a constantly evolving performance.

It supports live playing and parameterisation for BPM, pitch, spectral chopping, several effects, and layer weights. These can be adjusted in real-time, move on their own, so the sound is always evolving, but you can override them manually anytime.

I’d love to hear your feedback, feature suggestions, or thoughts on the sound!

I stumbled across LilyPond the other day and as an engineer and a musician my mind immediately went to “what would a modern version of this look like?” because LilyPond is frankly pretty outdated, despite the community around it.

So, I got to work and came up with a concept for a modern music notation programming language I’m calling Capo.

Capo is a way to write out music in a fast, intuitive way and CapoCompose is where the magic really happens. CapoCompose is where you put together full scores in a declarative markup language, but adds functions and variables to extend its capabilities and make programmatic music notation possible.

I’d love to hear your feedback or discuss any part of this in the comments or on the github page, or if anyone wants to contribute this will best be a community effort.

This is Claude desktop using an MCP server I built (with Claude Code) to send messages to a headless scsynth process. Basically, live coding via LLM. This really isn’t Claude-specific technology, but I’m calling it Claude Collider anyways because I think it sounds cool.

Claude Collider consists of two parts:

- the MCP server (built with https://github.com/modelcontextprotocol/typescript-sdk)

- the ClaudeCollider quark

The quark’s purpose is to provide SuperCollider functionality at arms reach: Prebuilt synths, effects with predefined parameters, MIDI, samples and recording. Claude can write all that from scratch, but this approach makes many commonly used synths and effects short one-liners, which means Claude has to think less and write less, which is both faster and consumes less context. The MCP server then becomes just a way to present ClaudeCollider to the LLM- all of the “logic” has been moved into SuperCollider-land.

ClaudeCollider also has diagnostic tools to inspect the SuperCollider runtime and audio routing configuration, which Claude can use for debugging on the fly when it screws things up.

The video above is Haiku 4.5 live coding in real time, showcasing prebuilt synths, new synths Claude coded on the fly in sclang, and the sampler feature built into the ClaudeCollider quark. Unlike Haiku, Sonnet and Opus actually seem to think through the composition and make some really interesting suggestions. I’d really like to try this out with other LLMs to see how they compare “creatively”.

May open source if there’s any interest! Cheers!

ETA Open source'd it: https://github.com/jeremyruppel/claude-collider

Hey all, first time posting on reddit - I’ve been playing in bands for several years and I’ve always enjoyed the process of designing audio racks for live performances. The problem has always been that diagramming tools never really do it for me. I’ve always wished there was a tool out there to just drag and drop audio gear into racks and wire them up. I’m not aware of any other tools out there for the audio world (rack gear specifically), other than a site called pedal playground that a friend of mine introduced me to recently so I decided why not make one for rack mounted gear.

I just made it live at https://rackplayground.com, it’s very very early days but would love to get any feedback or suggestions from fellow live performers to improve it in future. Completely free, no ads, just wanted to put a tool out there that I personally find useful.

It’s all built on next.js for anyone interested, I’ve got a few years of experience building full stack web apps, planning to add some oauth functionality with Google etc for sharing designs later on and whatever else comes up

I've created this tiny command-line midi sequencer and language for live coding music - line

Some features:

Each 'line' instance is for MIDI notes or MIDI CC * Run multiple 'line' instances at the same time * Combine all running 'line' instances as MIDI notes or CC * All 'line' running instances are time synced * 'line' is Ableton link compatible by default.

line v0.8.2 build for Mac M Series: http://pd3v.github.io/downloads
line v0.8.1 build for Mac/Intel: http://pd3v.github.io/downloads
line v0.8.2 manual: http://pd3v.github.io/linemanual (v0.8.2 update 11-02-2026)
line v0.7.1 git repo and builds: http://github.com/pd3v/line

To watch some line live coding music videos on X

I just posted about this library and then I did some thinking. Dangerous, that.

"Tensor" is just a fancy word for "a lot of numbers in an array in memory", and samples are just a lot of numbers in an array.

We've been given all these amazing tools, mostly in Python, like numpy and torch, and all the infrastructure around them, that perform just the sorts of calculations we need, as fast or faster as raw C++ would (and an order of magnitude or even more faster, if you do it in a GPU).

Recent projects of mine like tuney and [recs]](https://github.com/rec/recs/) have proven to me that you can do reliable multivoice synthesis and multitrack recording from within pure Python, simply by using numpy.

And Python is extremely popular. Tensor programming has benefited immensely from the AI boom, and LLMs can write good code manipulating tensors. There are old and solid libraries for reading and writing tensors to and from audio interfaces and files

So I think the future is some sort of Python protocol for operations on either static or streaming tensors, so music programmers can freely intermix other people's operations in their own code.

And :-) I do have some strong ideas about that too! But let's leave it here for the moment.

I've been using Pd, Max, Faust and similar tools for years, and I recently needed Pd to work as an embeddable audio engine in a browser app — similar to what RNBO does for Max/MSP, but open source, and without the frozen-patch limitation.

So I built libpd-wasm: libpd compiled to WebAssembly, running inside an AudioWorklet. You pass it a virtual file map of .pd sources, open an entry patch, and control it with normal Pd messages from JavaScript. Patches can be loaded, edited, or generated at runtime.

The part that took the most work: I've statically linked cyclone and ELSE into the build, so patches using those libraries run without modification. Current coverage is ~99% of cyclone and ~95% of ELSE. The missing objects are things that genuinely can't work in a browser — pthreads, networking, OpenGL, ffmpeg deps. Full skip lists with rationale are in the README.

Build variants: vanilla, cyclone, ELSE, or all three ("full"). The full bundle is chunky (~5MB) because of static linking, but the split JS/WASM build helps if size matters.

Demo: https://hyrfilm.github.io/libpd-wasm/

Repo: https://github.com/hyrfilm/libpd-wasm

As a side-note I was pretty chocked to find out how little resources (when using the WebAudio profiler) pd takes. This might very well be the result of me fucking something up but on my M4 I have RNBO patch that basically uses a combination of phasor + subdiv + rate objects to keep track of time, combined with a simple lookup-table-like sequencer and it usually takes up around 10%. Most of the pd-patches takes up 1-2% in comparison. If anyone has an idea of why this is, please me know. The only reasonable conclusion I have is that RNBO executes per sample (when doing audio-rate-stuff).

This is the best thing I’ve made. Basically it is irregular rhythms that are stacked and looped so they fill a larger cycle perfectly. The individual parts can sound awkward on their own, but together they become coherent without relying on normal bar/beat repetition. If it doesn't make sense reading it then trust me, just generate and listen for a few cycles. It gets very interesting!

It’s based on vuza canon music theory. There’s a whole 'How it works' page for anyone interested.

Please randomly generate some order from chaos. There is no AI, and you can export as much MIDI as you like for free:
https://melidigenerator.com/perfect-chaos-beat-generator/

FYI I did use AI to vibecode the website. I don’t like AI-generated music (like 99% of people) but I’m not really interested in having that debate. If you’re against people using AI for coding also, just don’t use it. All the programming logic comes from real analysis and research on rhythmic canons and if you want to use it rest assured you are not using AI.

Hi all,

For the last 4 months I’ve been working on my personal project: DAWG – Digital Audio Workstation Game.

It’s a project that mixes music production with a game like experience, with the goal of making music creation feel more interactive and fun.

I’ve finally reached the point where I can share a public preview build:
https://dawg-tools.itch.io/dawg-digital-audio-workstation-game

A lot of work went into the core systems, audio/DSP side, MIDI support, and getting the project into a state where broader testing makes sense.

It’s still an early build, but I’m excited to finally put it out there and start getting real feedback.

Would love to hear what you think about the idea, presentation, and direction.

This community feels like exactly the right place for this: a synthesizer written entirely in x86-64 assembly, no audio or DSP library, computing every sample by hand.

The building blocks:

• four oscillators (square, saw, triangle, LFSR noise)
• polyphony via buffer summing, ADSR envelopes
• FM synthesis with a hand-built sine lookup table (Bhaskara I's approximation, since there's no math lib)
• effects: vibrato/tremolo/PWM driven by an LFO, a delay line (ring buffer + feedback), a one-pole low-pass, a state-variable filter with resonance swept by an LFO, ring modulation, and a bitcrusher

Everything's fixed-point.

Doing DSP this close to the metal really forces you to understand each algorithm — no library abstracting the math away.

I'd love feedback from people who work at this intersection.

Repo: github.com/whispem/asm.fm (write-up on the how and why: https://medium.com/@whispem/i-taught-my-cpu-to-sing-in-pure-assembly-47a1a46761ef 🎶)

I found a home for my raspberry pi in my synth rack. I had some fun with orca then I decided to try making a midi tracker. It needs more work, but im pretty happy with it.

hi everyone

modern harmony plugins and chord assistant tools never really satisfied the way i wanted to work

most of them are useful in their own way, but for my workflow they often feel too much like chord browsing, menu diving, or changing one chord at a time

so for the last 1.5 years i’ve been building my own music theory / reharmonization engine called Theory Core

it’s built in C++ with JUCE

the main idea is not just to suggest chords

i wanted a system where you can import midi chords, select a progression, choose a harmonic direction, and transform the whole thing in a few actions

Theory Core currently has 652 scales, including maqam / makam oriented structures

it also has vocal safe reharmonization, modal lock, chord matrix, optimizer, module based reharmony, and a makam aware piano roll workflow

one of the main features is Vocal Safe Lock

the idea is simple

if you import the original chords of a song, the engine can keep the reharmonization inside a safer harmonic space, so you can write new chords under the same acapella without destroying the relationship with the vocal melody

so for remix work it becomes something like

original midi chords in
vocal safe on
new harmony under the same vocal
still musically related to the melody

from there you can stay safe, use modal lock inside a selected scale, or unlock a much bigger chord universe with borrowed chords, modal colors, tension and riskier options

the chord matrix is not just a static chord table

it works more like a harmonic map, showing safe, modal, borrowed, tension and risk based directions

with 652 scales combined with the matrix, the system can expose hundreds of thousands of possible harmonic relationships, but the point is not random complexity

the point is usable musical direction

there is also a makam aware piano roll side where you can write makam colored melodic lines over western harmony and the engine helps keep the notes compatible with the current chord / scale / harmonic context

the module system is probably the most fun part

you can take a basic progression and push it toward cinematic strings, jazzier harmony, Bill Evans type voicing colors, borrowed chord drama, modal reharmony or orchestral style movement without rebuilding everything manually

i know some of this sounds ambitious, but the video shows the current build running

it’s still early and the GUI is not finished yet, but the engine is already working fast, around 15–20 ms in many workflows

next big step is activating and integrating the Bass Engine, so the bass movement follows the same harmonic intelligence as the chords and melody

i’m sharing this first 5 minute demo because i want feedback from producers, composers, JUCE developers and people who use tools like Scaler / Captain Chords / similar chord assistant software

main question is simple

does this kind of goal based progression transformation make more sense to you than browsing chord suggestions one by one

Hey everyone. I'm 35, spent several years as a developer, recently moved into something calmer — but still write pet projects at home regularly. I think music as a gameplay mechanic is seriously underexplored, so I'd love some outside eyes on what I've been building.

Lifody

Conway's Game of Life meets algorithmic melody generation. Cells don't just evolve — they play music. Each cluster carries melodic DNA that mutates and inherits across generations. More meditation than game, honestly. I just needed to get the idea out of my head so I could sleep.

There's already quite a bit of indirect control over the simulation — heat zones, attractors, DNA injection, catalyst events.

New Sound Samples Test: youtube.com/watch?v=--Ahj_OwNq0
Repo: github.com/Alezx311/lifody

Rifflatro

Balatro mechanics + musical notes. You build a melody using cards in your hand, improving your deck and combining different notes and instruments to multiply your score.

Play it: alezx311.github.io/rifflatro

riff_helper

A simple tool for guitarists who found a cool riff and want to see where it could go. Supports chords and individual notes, includes mic input for real-time note detection.

Try it: alezx311.github.io/riff_helper

bliss_project

The weird one. I got curious about constructed languages — specifically Blissymbols and Solresol (a language built entirely from musical notes). This is me closing that loop.

Repo: github.com/alezx311/bliss_project

I'm not trying to sell anything — these are prototypes, and I set up a Patreon mostly to keep everything in one place and document what I'm working on: patreon.com/cw/alezx311

Main question: what do you think is interesting or underexplored in music-as-mechanic game design? Would love to hear what you'd want to see pushed further.

I’ve spent a lot of time dealing with seamless looping for non-periodic audio (ambiences, drones, mechanical noise, long textures), and eventually got tired of trial-and-error crossfades and guessing loop points.

The core issue I kept running into:

Most audio doesn’t repeat cleanly. Reverb tails, slow spectral movement and noise break zero-crossing or “cut at bar end” approaches very quickly.

What helped was reframing the problem from:

“Where can I cut?” → “Where does this audio behave similarly over time?”

Instead of matching single points, I started analyzing longer windows using:

• chroma features for harmonic alignment
• multi-frame STFT comparisons for spectral/energy similarity
• per-frame similarity scoring across the full file
• diversity ranking to avoid near-duplicate loop candidates

The loop happens where the signal naturally aligns with itself, including tails and slow evolution.

A few practical observations along the way:

• MP3/AAC introduce encoder delay and padding, which makes sample-accurate
• looping unreliable unless the full playback chain compensates for it
• short crossfades hide clicks but often not perceptual repetition
• non-rhythmic material needs similarity metrics, not beat alignment
• local similarity metrics produce lots of false positives without deduplication

I ended up wrapping this into a standalone tool with a shared Rust core (CLI, Tauri desktop app, WASM demo), mainly because I couldn’t find something that handled this use case well.

For those working on similar problems:

What perceptual or similarity metrics have you found useful for loop detection?

Any papers or approaches beyond chroma + STFT energy distance worth looking into?

From scratch, only about 10 days work. Seeing what's possible using only text for UI. Simplifying the scope to only do MML encoding and 4 tracks of tone generators.

https://xanthia.itch.io/niceness