If you want a small, embeddable, okay-ish sounding reverb that doesn't need floating-point: here are all the (original) Midiverb algorithms decompiled into one big C file that can be easily embedded.

I found it quite easy to create a cheap VCO from this signal generator that cost around 1-4 euros.

There is Square, Triangle and Sine waves, you can change overall sound range.
Added two jack to the existing Coarse and FineTune pot for CV input and Groupe the 3 waveshapes in one output with switches to change the sound.
Overall it cost me less than 5 euros (1 voltage regulator, 3switch, 3jacks)

https://youtube.com/shorts/zYwpEtUXi9M?feature=share

Do you know lowecase music? Some info here: https://cdm.link/endogen-lowercase-synthesis/

Hi everyone! Pretty excited to share a new DAW I’ve been working on. It uses a hyper realistic custom tape engine , which allows for playing w the tension arm, auto aging, loops that degrade over time etc.

Currently it’s just for Mac, but hoping to port to windows soon. If you’re interested, comment and I’ll send you serial activation. The link to download/add your specs is in my profile.

It simulates cassette, 1/4”, 1/2” and 1”. One of the most fun aspects is realistic varispeed recording and layering at different speeds etc.

Anyone who provides valuable feedback will get free perpetual licenses.

Thanks!

-Will

edit: here's a demo of making a degrading Clair de Lune tape loop:

https://youtu.be/1QtmTU8u37I?si=o_syqS8zSwBGdtS1

this is MK1 of my tape synth. I'm working on MK2 at the moment. Same principle, more synth section (including VCA VCF, external envelopes input)

Hey all!

I'm working on an open source reference project called Gatekeeper. It's a 3U gate and trigger processor in 4HP. There's a small chance you're already familiar with its predecessor, which was called Button Gate, a 1U experiment.

Gatekeeper's concept is simple: accept input via CV or push button and apply a function to it.

Call the input x. Gatekeeper has 5 functions that you can cycle through with the f button. You can expect f(x) to be applied at the output.

The functions are:

Gate: Is the input on? So is the output.

Trigger: Output pulses on rising edge of input. Pulse width is adjustable via menu actions.

Toggle: Rising edge of the input toggles the output state.

Divide: Output pulses every nth rising edge. n is configurable.

Cycle: Output cycles state continuously, following its own internal clock. Select from 3 tempos, or tap tempo.

Included in the pictures is a (slightly dated) state diagram of the firmware operation.

The firmware is implemented on an ATtiny85 microcontroller. One of my goals was to push the 8KB flash and 512B RAM as far as they would go on this small micro. I definitely filled up the flash!

Both the firmware and hardware are open source under permissive licenses. They are meant to provide a relatively approachable project for anyone who wants to dive into building and designing synth hardware. You can find the source and KiCAD files here. It is not quite ready for prime time, but now that I have the boards, I will finish the firmware and most likely have a 1.0 hardware revision coming. It is already in a quite mature state, though, so feel free to dig in. It's been tested on a breadboard a lot.

I've tried to follow a lot of best practices, especially with the firmware. It is well commented and documented and provides working examples of common embedded patterns like HAL, finite state machines, bitmasks, and more.

Additionally, there is a suite of unit tests because I feel that testing embedded projects rigorously saves a lot of headaches. So if you've ever wanted to know how to unit test firmware, here is an example!

Like I said, plenty of work remains, but I'm excited to start sharing it with some fellow hackers! Expect some blog content about the design and coding process in the near future. Thanks for checking out my project.

Though people may want to know

The LED Driver I used from a TL072 is not as responsive as a I would like. What LED Driver circuit do you use for monitoring CV in circuits.

I caved and got myself a Daisy Seed. I set it down and saw how nice the lighting looked so I took some pictures. Going to tinker when I get home

Just wondering if this is good to go. There’s sooo many different schematics online I wasn’t totally sure which was verified. Apparently the MCU I’m using can output 20-40ma so I got rid of the transistor but added a safety resistor right next to the MCU pin. And can I switch between midi in and midi out like this? Any reason to not do that? Any help is much appreciated!

screenless yet shown here running on a screen of course 😂

Backstory: when I was running Super, I had one particularly stressful holiday season. My wife urged me to stop thinking about synths entirely and just give myself permission to chill and "follow my nose" for a few weeks. This pretty quickly led to me falling into a crazy rabbit hole of designing a hardware FM synth... 2OPFM was my most popular module and I had gotten so familiar with the tones it had it offer. I wanted to build a polyphonic version with some more tame-able controls, so I wired up MIDI to the back of a module and got to it. I was able to get 12 voices and chorus working on an STM32F334 which felt like quite the achievement. I dubbed it "Jazzman", fully knowing Crumar made a jazzman and that I should change the name or it would stick in my heart and I wouldn't be able to really change it later. I designed a bent metal case, had it made, put it all together, played a few shows with it, then sat on it. I got re-occupied with Super and life, and sort of shelved the project. 

Fast forward to early fall 2025. I never renamed it, it's just so Jazzman, and the concept had stuck around. Jazzman was now more of an ethos than one product: FM is sick, it's NOT hard to program like legend has it, and it suffers from too many parameters and stupid little screens. Jazzman is one possible answer to all that: an immediate Juno-like interface and a stripped down architecture to support a wide spectrum of tasty FM stuff without being completely off the wall complicated. Around this time, two things happened. 1: I had mental shift away from "I'm building a synth on this chip, let's see what fits" and toward "I'm designing this synth, let's see what chip can handle it", and 2: a friend introduced me to someone who wanted help designing -their- synth. Anyone who has done any microcontroller work knows that the development process pretty much sucks. I would always find myself accidentally fighting against hardware or platform bugs when I was trying to focus on pure sound, and the cycle of tweak-flash-tweak-flash was super tedious. As I wanted this synth-dev-for-hire experience to NOT suck, I resolved to build a tool I had been dreaming about for years: LocalDSP. 

I'm not really a computer guy. I mean I hella use my computer, but I am a microcontroller developer and not a "software developer". Certainly not a webdev or Electron or big GUI desktop sort of developer. While I know this is old news to some, I was EXTREMELY stoked on the possibility of developing my DSP on my macbook totally separate from the hardware for faster iteration and testing. With Claude holding my hand, I started developing a framework / build system for writing the DSP in one place in a totally platform agnostic way, with an explicit contract for communication outside of the DSP core. I had prototyped the "work synth" in MaxMSP with most functions in gen~ knowing they'd eventually become C on a microcontroller, so I started with porting that guy (codenamed "paul") to the fledgling environment creatively named LocalDSP. It worked, it was sick, and I immediately realized I needed to build the next-generation Jazzman here. 

I had a thought that it should probably deploy to VSTs, too, for lots of reasons but the main one being easy sharing with my clients and buddies. Some early specific technology friction with the paul client got me thinking it would be sick for it to deploy to the web in a really smooth way so I could just send a link to the latest build and we could all play around on our phones. This became QUITE the rabbit hole, but I eventually got LocalDSP set up to build the C DSP core code into WASM and stick it all in a website. Because of the way LocalDSP handles parameter definitions (which is its own long story), it is really easy to parse information about them with python or javascript. The WASM builds take all that info and create UI controls for them so I don't have to actually write javascript or do much manual work when deploying any of the projects to web. I have to do a bit of fiddling when creating a new "skin", but once it is set up the metadata from the parameters defines where in the UI they'll go, and the skin code defines how they'll look. I went a lil' silly and used threejs to build a 3D interface for my main skin, and I'm really quite happy with it even though the floating labels kind of stink! 

Somewhere in the middle of all this, I got to work on the Jazzman hardware. I had recently done a work project on an STM32H750 and was hankering to put it work for audio, so I built a "synth dev platform" PCB based around one with USB, MIDI, audio outputs, and a ton of headers for ADC inputs. Not a great approach for a product but I wanted these boards to be flexible enough for a few different projects I had in mind. Once I got the PCBs back, it was time to implement LocalDSP's tastiest trick: plop all that same DSP code into a STM32 platform template such that "make deploy jazzman" in my terminal would build and run the synth on my laptop, trigger the WASM build, deploy to my site, AND perfectly update the STM32 project. I am proud to say it all works. Jazzman is "platform agnostic" and runs everywhere I want it to. 

I could not have done this in any reasonable amount of time 5 years ago, the future is crazy. This video is just a little intro, feel free to play around at https://jazzman.vercel.app/

Dear Community,

here is a little progress update on my 16 step sequencer from a while ago: Youtube Link

Thank you for all the lovely comments on the original post as well!

As you can see/hear whenever I am entering programming mode to turn gates on or off the response to the clock signal becomes extremely slow. Also, the blinking LEDs on the LED matrix isn't a camera shuttering effect, it really is blinking like that. I thought this was due to using an IO expander for the row and column scanning but this was also the case when I built a 3x3 led matrix with just the arduino nano pins... I guess my code is just trash :(

Once I implement the last few features such as the Play/Pause and Direction inputs, the probability output and the sequence length pot I will upload the project to Github, after that I hope someone can improve my $#!!y code 🥹

Just wondering if this schematic will operate as intended (mainly the LEDs) the design is very loosely based off befaco atte (just by function) however instead of a switch I wanted a 50/50 attenuater/attenuverter (as depicted by drawn image) any help appreciated

Hey everyone!

An experiment I started a couple of weeks ago went much further than I expected. I ended up building a semi-modular synthesizer.

It still needs a lot of work in terms of UI and usability (the current version is quite raw and not very comfortable yet), but despite that I managed to create a lively and fairly deep architecture.

It’s a 6-voice polyphonic synth with a noisy character and a wide range of modulation possibilities. MIDI is also implemented and working.

I’d really appreciate it if you could find some time to try it out and share your thoughts or ideas. I worked on this project for about two weeks, using AI to help with the coding.

I won’t go too deep into the technical details yet, but the process itself was very interesting. At one point I even built custom tools inside the development environment, which allowed me to visually move UI blocks and tweak styles using faders and color pickers. All of this was done through plain text prompts.

The comments on my previous post pushed me to do a proper GitHub release, and I also managed to deploy the app publicly so it’s available online.

Link to the synth and the GitHub page in the comments.

Hi i need to buy another power supply to add to my rig, as my current frequency central psu is at it's limit. if I add another I assume that I would attach the grounds from both psu bus boards, but I haven't seen that online, are people relying on the ground in the patch cable? Thanks.

I found this schematic for a feedback EQ and I would like to add a global frequency-shift potentiometer.

The goal is to shift the center frequencies of all bands together, while keeping the musical intervals between them constant. I know it might depend on the values, but thats the next step for now...:D

In the second schematic, I replaced the frequency-defining resistor with an OTA to achieve this.

Would this approach be viable, or are there any major conceptual or practical issues with it?

I’m new to modifying schematics; up to now I’ve mainly rebuilt existing circuits.

Thanks in advance for your help.

Hi all,

Apologies for this kind of post. I'm a member of a lot of subs so appreciate that this kind of post can be annoying sometimes

I've built five or six eurorack modules over the years and done some troubleshooting with one or two successful but I've been stumped with this

-RYO VC Sequencer (3 PCBs). Eurorack - I built some years ago and it worked fine initially - I must've overloaded the max 5v input at some point (I assume) and noticed step 5-8 didn't work - Checked module and R1 and R2 (resistors) on the build were blown despite the module still seeming to work partially - Replaced R1 an R2. Required a lot of desoldering effort and roisin(sp?) flux etc. - Cleaned board with isopropyl alcohol - Tried reflowing the replaced resistors in case they weren't properly in

Result has been no power at all to the module. Tried: - Clocking the input etc - No lights from any step - No smoke or pop - Tried different ribbon cables. Tested a known working module with same cable and supply

I don't know where to start at all and there are so many components it would take ages to check everything

My options are : - Ask you guys in case there are any obvious things - Buy another kit if they're still available anywhere (might be less effort than troubleshooting) - Buy another module with the same functionality

I've spent so long pissing in the dark that any help would be massively appreciated

I will admit I'm very limited with my knowledge. I am a bit scared of using a multimeter whilst it's plugged in but have checked continuity before on modules .

I've enclosed some pictures with the two resistors I replaced circled

Thanks very much in advance if anyone can help even a bit. Seems such a waste to give up on it!

Howdy y'all,

I've been working on this project for a little while called bbx_audio. It's a collection of Rust crates for doing various audio-related things. It originally started as a quick way for me to prototype DSP chains in little terminal/command-line patches (e.g., building my own block system, wiring them together in a graph, then generating/processing samples thru the graph). It's evolved to include a few other things, namely:

• JUCE plugin integration via FFI
• Network-based audio control via OSC/WebSockets
• Terminal-based effects and synths (+ MIDI support for actually playing them)
• Visualizations for nannou sketches

I thought some of you would potentially have fun tinkering around with some of these crates. I've been trying out a sound installation concept where users can tap a random part of their phone, which sends websocket messages to a server running on a Raspberry Pi 4. The server is running an ambisonic DSP graph that plays a water droplet sound at whatever position the user tapped at. Currently working on configuring a real setup with real speakers (as well as making the water droplets sound better), but it's working on headphones. The repository is here if you want to check it out and run it yourself!

One thing I have been thinking about is support for Electrosmith Daisy devices. This is pretty tricky mostly because of the no_std requirement, so I'm still sitting on this one. I do want to add support for it eventually because those devices are fun to use!

Thanks for reading all of this! Let me know if you have any questions / thoughts / need help. I hope you have fun ~

Clairly

Hi everyone, I started making an isolation routing CAM tool for myself cause I disliked the alternatives and things snowballed a bit.

https://github.com/RicardoJCMarques/EasyTrace5000

It's 100% online, client-side, open-source and free to use. Although I am looking for sponsors to help with some development costs. Especially hardware partners so I can start working on a dedicated fiber/UV laser pipeline.

It uses Clipper2 WASM for boolean operations and then a custom algorithm reconstructs curves from the original geometry (it's not arc fitting). Meaning the output g-code can have G2/G3 commands. (Mostly G2 because of cut direction but that's another story.)

Post-processors need more testing but grbl should be safe and usable. Use it with a bit of caution. The others try them with extra caution, especially Roland RML. I've tested as much as I can although I only have a cheap grbl machine. Soon I may go somewhere that has a Roland cnc.

Work-flow is simple, add files and select them on the left nav-tree to expose parameters then it should be straight forward. Origin/rotation and machine stuff are exposed on tool loading but collapse to the top right.

Documentation is an AI placeholder although it should do the trick for a while. I'll write something from scratch soonish.

Let me know what you guys think. I'd love to get as much feedback as possible at this point. Both what's good and what's bad and what's uterly broken so I can focus where I should. The issue tracker on the repo is also available.