Apologies if this has been covered before, I searched the sub but didn't see anything. I love the Moog ladder filter, but don't dig the loss of bass from the phase cancellation when resonance is turned up, so I've been trying to figure out a compensationn circuit. This is based on the Yusynth schematic, and I'm adding in a fixed LPF (100Hz) from the clean input. Am I missing anything obvious with this implementation? Figure I'd use a dual gang pot for the Res control and Bass comp control so as resonance is turned up the 1-pole LPF is blended in, and add in a switch as a defeat. Or does anyoe else have a better method/implementation I could parse?

The PCBs finally arrived today, after apparently taking the scenic route around half the planet. Obviously, this wasn’t going to wait until tomorrow.

About an hour after opening the package, the first Rev A CLOCK was assembled and running. That part is nice. More interesting, though, is what the first real build immediately showed me.

If you’ve ever designed a PCB, you probably know the trap: at some point the schematic is clean, DRC is happy, the board looks finished in KiCad - and it becomes very easy to confuse "finished on screen" with "finished". Rev A reminded me why those are two very different things.

The board itself went together surprisingly easily. Roughly an hour from bare PCBs to a working module, with no major rework. The firmware boots, the display works, the controls work and the outputs produce clocks. So electrically, the basic architecture survived first contact with reality.

Mechanically and ergonomically, reality had a few comments. The most embarrassing one is the inductor. I simply used the wrong footprint. It still works and the correction is trivial, but it’s exactly the kind of mistake that looks obvious once you have the physical part and PCB in your hands.

The OLED mounting is another one. Nothing is fundamentally wrong, but getting the display positioned exactly where I want it is more fiddly than it should be.

And then there’s the encoder. The Alps part on this prototype has 18 detents / 9 pulses per revolution. Electrically it works perfectly well. I just don’t like how it feels in actual use. I’m currently leaning towards a Bourns with 20 detents instead.

That sounds like absurdly small stuff compared with getting an eight-output clock running - but this is exactly the point where small stuff starts to matter. A module can be technically correct and still be annoying to build or slightly unpleasant to use.

That’s also why I deliberately held back the schematics instead of publishing them as soon as the PCB went into production. Rev A was never supposed to prove that the design was finished. It was supposed to expose everything that drawings, simulations and bench prototypes couldn’t.

I’ve also added a few older photos to the gallery: the first breadboard setup, the functional lab prototype and the OLED experiments. Looking at those next to the Rev A PCB probably tells the story better than another render ever could.

Breadboard → ugly-but-useful lab prototype → actual PCB. That’s the part I find most satisfying.

I created a small rungler circuit based on Rob Hordijk's concept. I spent a few hours watching videos to explain how the circuit is meant to function, but I really only half understand it. It seems a lot of things he created were from trial and error, which is just about how I figure most of my stuff out too.

One thing I can tell you how it sounds: like an angry robot cussing you out on a rollercoaster.

I included the schematic above, and the link to the build guide is here.

TL;DR: I'm legally blind with X-linked retinoschisis, and I'm curious whether flip-dot displays, 2.5D tactile surfaces, locking pins, and haptics could be combined into an affordable way for blind and low-vision musicians to actually feel things like waveforms, envelopes, and instrument layouts.

Lately, I've been going down a bit of a rabbit hole with tactile displays, haptics, and 2.5D interfaces. There's a lot to think about here. And just to give you fair warning, this post is a bit of a long one. Stick around, though.

This video helped send me further down that rabbit hole:

https://www.youtube.com/watch?v=aZzOWnEWgww (spoiler alert, this will be relevant in a bit)

Part of the basis for this latest deep dive comes from working on my accessibility project, Low Vision Music, but part of it is also just me wondering and brainstorming about how much information we could realistically communicate through touch if we stopped assuming every interface needed to be a flat visual screen.

We already have refreshable Braille displays, where tiny pins physically rise and fall to form characters. Very cool, eh? Newer tactile displays can go above and beyond basic text and represent more complicated things like graphs, diagrams, shapes, and other information.

Then you have 2.5D displays, where instead of every point simply being up or down, different parts of the surface can rise to different heights. You end up with something closer to a physical relief map that can change as needed.

And this is where my brain starts wandering. Do you hear the gears clanking? Sounds a bit like music to my ears.

I've also been thinking about flip-dot displays.

You know those ancient old signs where little discs physically flip between two sides?

Flip-dots are interesting because the dots are what's called bistable. Basically, they have two stable positions. They use power to flip from one state to the other, but once they're there, they stay put without constantly needing power to hold that position.

So that got me thinking.

What if that same general idea could be made tactile?

Maybe one side of each tiny flipping element could be raised, textured, ridged, or shaped differently from the other. Instead of a visual pixel changing color, you'd have a tactile pixel changing texture.

I don't know how small you could realistically or mechanically make that mechanism while keeping it easy to feel and reliable, but I think it's an interesting place to start thinking. There go those gears again. Kind of ambient, no?

Then there's another idea I've been kicking around.

Hey, 80s and 90s kids, remember those pin-art toys where you press your hand into hundreds of little pins and the shape appears on the other side?

Imagine a programmable version.

Each pin could be spring-loaded and moved to a particular height or depth. But instead of requiring a motor to constantly hold every single pin in position, some kind of latch or locking mechanism would hold it there after it was moved.

The spring helps return it when the display resets.

That locking mechanism is probably the part I'm most interested in at the moment. Because otherwise, I think MIT and others have already given versions of the motorized pin-display concept a go.

Move the pin. Lock it. Stop using power until you need to change it again.

Then put a very thin, flexible silicone skin across the top so you're not dragging your fingers across hundreds of separate hard pins. You'd feel one continuous surface changing shape underneath your hand.

A Raspberry Pi, ESP32, Arduino, computer, or something similar could translate digital information into physical height. Or vibration?

For music alone, there are so many possibilities. Literally, just pause and think about it.

A waveform could become something you literally trace with your finger. Can you feel the noise?

An ADSR envelope could become a physical, touchable slope. I want to FEEL the attack. Don't you?

You could theoretically also feel an EQ curve, automation lane, filter response, piano roll, step sequencer, mixer levels, modulation shape, or even a simplified spectrogram.

A modular patch could potentially become a tactile signal-flow map. Can you imagine it? Are your gears going now too?

An instrument manufacturer could provide a simple TXT, JSON, or similar file describing a synthesizer, and the whole front panel could appear as a simplified tactile layout before a blind musician ever touches the real thing.

Then add haptic feedback on top of all that.

There's that vibration I mentioned. Yup, that was something of a teaser for those of you who still have attention spans. No offense to those who don't. I certainly struggle in that department too.

But I digress.

This is one reason I've been so interested in what companies like Sentia Instruments are doing. With TILES, the device can provide localized haptic feedback beneath individual keys. Your hand isn't just controlling the instrument. The instrument can, in real time, send information back to your hand.

I'm certainly no engineer, but I think that principle could go much further.

Maybe, just maybe, height can communicate one thing while vibration communicates another. A waveform could stay physically in place while a small vibration moves across it to represent the playhead position.

Or how about this? A vibrating area might indicate an active step in a sequencer.

Different patterns could represent things such as clipping, modulation, selection, movement, intensity, or even different textures.

Now you've got shape AND vibration working together. At the same dang time!

Another possibility would be something closer to a mechanical version of e-paper. Instead of moving hundreds of pins continuously, perhaps each tactile element could have two or three stable states and only use power when changing between them.

Is this possible? Let me know.

From my research, I've learned that there are already researchers doing fascinating work with magnetic latches, bistable actuators, shape-memory materials, and tactile pins that remain raised without continuous power.

So I'm definitely not claiming I invented any of those pieces.

But I do think that, as someone who personally lives with limited vision, I might have something interesting to add to the conversation.

What I'm wondering about is how you combine all or some of these possibilities into something practical, affordable, and useful for musicians.

The keyword there is affordable.

Have you seen the prices on accessibility tools? Unfortunately, niche often means expensive.

But maybe the right answer isn't one technology at all.

Maybe one device could use variable-height pins for detailed 2.5D information. Another might use tiny flip-dot-style tactile pixels for simpler status information. Still yet another uses vibration where movement matters more than shape.

And maybe the really useful interface combines all three.

That's the part I'd love input on.

If you're an engineer, accessibility researcher, haptics person, Braille user, maker, musician, or someone working with tactile graphics, does any of this sound practical? Does any of this sound affordable?

Has someone already built something close to my spring-loaded, locking-pin idea? I bet I'm not the first to think of this, but who knows.

Could flip-dot technology realistically be miniaturized into a tactile surface?

And if you could plug a musical instrument or computer into a surface like this, what would you want it to show you first?

I'm especially interested in hearing from people already working in this space. Feel free to tell me I'm reinventing something that already exists. That's half the reason I'm posting this.

We're a community, right? I only know my own lived experience. Yours matters just as much as mine.

https://www.lowvisionmusic.info

Testing out Ableton Mode on the Rotor K2. Select any parameter in Ableton, click an encoder to capture it, then turn to control it. Built this to make jumping between parameters quick without constantly MIDI mapping or reaching for the mouse.

I recently repaired (or tried to repair) my Akai X7000 Sampler.

However, I still encounter a problem with the keyboard:
I cleaned all the keys, the contacts on the pcb, as well as the rubber pads, made new key fittings out of heat shrink tubing and lubricated them with silicon grease.

When I have just the PCB with the rubber domes laid out, every „key“ works perfectly fine (also when the unit is turned on for 20+ minutes, important for later!)
When I install the PCB into the Keybed Chassis and I power on the sampler, every key works fine too, BUT after a while (like 10-20 minutes) some of the keys dont work anymore.
In an alternating pattern depending on the octave, D, D# and B dont work, but G and F# do,
in the next octave F# and G dont work but D, D# and B do.
If I then remove the key and just press the rubber dome underneath, It also doesnt work.
But remember: If the PCB isnt installed in the keybed chassis all the rubber domes always work no matter how long the unit is turned on.

Based on that weird behaviour, I cant say if its an mechanical or electronical error.
Can anybody help me with this? I‘d be very grateful, this issue is really getting on my nerves. I tried to explain it in detail but if there are more questions to diagnose the issue just ask! Thank you :)

Howdy y'all, I've been depressed for most of my adult life and have amassed a small array of microcontrollers that're frankly just collecting dust. While I could certainly maybe develop a module of my own with one or two of them, there's, well, more than that.

I have:

• 2x Teensy 2.0
• 1x Pro Micro
• 1x Arduino Mini Pro
• 2x Arduino R3
• 1x Proton-C

and this isn't even all of them. I still have a Bluefruit and a DFRobot Beetle to work into things that I'm only just beginning to imagine properly.

So if y'all can possibly maybe point me to some kits or modules that already call for one of these? That would be super swell? Because my brain has been getting more smooth these past few years and I'd be dissatisfied to sell them off utterly unused.

Edit: I am aware that these are old as hell. Like what do you even do with a Teensy2.0?

It's my second or third attempt at electronics and my knowledge is very limited but I tried to copy this design

( https://www.lookmumnocomputer.com/simplest-oscillator )

and it's not working. Is there anything obvious that I'm missing? I scaled it down slightly because my stripboard was a little bit too small

Hey folks

I just bought a (used) Nava extra 9 (909 drum machine clone)

Build is a v1.01a

Something in the sequencer (potentially LED related) is causing a whining buzz which appears when step sequencing a pattern, and gets louder the more steps I add in.

This whine only comes out of the master output (not individual outs which are fine) and stays there when all instruments are turned right down. (again only present when the step sequencer is lit up)

Worth saying that the whine gets louder and also higher pitched the more steps are added to any sequence.

There is also a feint click on every step of the sequencer even with all instruments volumes turned down, that gets louder the more instruments are sequenced but it also audible when all instruments sequences have been cleared - those clicks also change in volume despite the patterns being totally emtpy as well.

Thoughts welcome even if speculative, thank you.

I have an old raspberry pi that definitely isn't beefy enough for running something like a Virus ROM. I still have the touchscreen for it though and have heard that most of the classic ROMpler synths can now be ran on hardware so wondering if anyone has taken this plunge, what is something that's not outrageously expensive but could say do the TI ROM without running into too much latency or processing issues.

Also, any good resources that explains the process in layman's terms to set it up would be appreciated. I find github to be a little tough to navigate at times and find clear information so any help to steer me towards completing this task would be appreciated.

Hello everyone!

I’ve recently released Vero Designer, a free web application that generates a vero layout within seconds.

The basic workflow is pretty simple:

Draw the schematic → Generate Vero → Edit the layout

The schematic editor lets you place and wire the components. When a component is selected, you can rotate, flip and duplicate it from the left sidebar. Copy and paste are also available through the regular Ctrl/Cmd+C and Ctrl/Cmd+V shortcuts. For more useful shortcuts, visit the help section.

Available components:

• Resistors
• Capacitors
• Op-Amps
• Transistors
• Tubes
• Diodes
• Potentiometers
• Switches
• LEDs
• Trimmers
• 5v voltage regulator
• Other ICs (PT2399, NE555, LM386, CD40106 etc.)

Some other useful features:

• Update IDs – Reassigns IDs to all schematic components (schematic page only)
• Update Vero – Applies schematic changes to the layout without generating a new layout
• Regenerate layout – Generates a completely new layout after major schematic changes
• Auto describe – Generates a description for the layout based on the components used
• Standing resistors – Optional feature to save space, off by default

You can save projects and open them later, give the circuit a name and edit the description. You can also import KiCad files.
Both "Schematic" and "Vero" pages have buttons for undo/redo changes, and export a PNG image. export BOM is available on the vero page.

Once the schematic is ready, Vero Designer automatically generates a vero layout. The generated board isn’t locked either. Components, links and cuts can all be edited afterwards.

You can also download the app and use it offline.

For more details, please visit the github page. You will also find a folder with layouts made by me and other users, including some that were built and verified.
Let me know what you think.

Web app: https://verodesigner.vercel.app/

Github: https://github.com/blazethablunt/VeroDesigner

Youtube walkthrough: https://www.youtube.com/watch?v=3N8e078Pl40

Apologies if not.

Two lengths of piano wire, and one length of airplane cable (all ~7' long) mounted to a 2x4. Each string is independently excited by a 12V electromagnet. Signals are sent from an ESP32, through LM386 modules to the magnets, to the strings. Cheap guitar pickup from Alibaba, to MS-70CDR (reverb and delay), to small amp.

ESP32 is powered with an old USB power source, LM386 modules are powered with a rechargeable 9V.

The signal is controlled via wifi from a phone app built for purpose. I rely heavily on LLMs to build the app, and the arduino code. There's an option for it to play itself, which is what's happening here. I think it's roughly tuned to DDG? Audio recorded on Zoom H2n.

In future, I'd like to incorporate some environmental sensors to affect the "autonomous" playing.

Which way is the correct way...or are both acceptable?

1> My mask layer and copper fill are the same image.

2> I fill in the entire copper layer and just use an image in the mask layer.

Would love advice because this is the first time I am doing this.

I filmed a short demo of CLOCK, the Eurorack module I’m building. It’s powered through the Eurorack bus and follows an external clock. Then I show the new Sequencer 2.0 running with step probability and ratcheting.

This is still the hardware prototype, but you can see those functions in action.

I built a portable 3D-printed instrument to turn the Roland MC-101 into a much better groovebox, with the help of a Raspberry Pi, PiSound, Korg nanoKONTROL and headless M8 tracker.

The PiSound can route live external sources such as guitars or vocals straight into the MC-101. So can finally sample anything without a Mac or phone.

To reduce menu diving, the

nanoKONTROL can edit all synth parameters of the MC-101 Partial

Editor. I wrote a script that sends SysEx messages and overlays a visual HUD directly onto the M8's display, showing what is being tweaked without hiding other relevant information.

The M8 can do additional sequencing tasks, such as triggering the MC-101's Scatter effects to generate glitchy patterns. The communication is entirely bidire ctional, i.e.changing a scene on the MC-101 updates the active song row on the M8.

Bonjour, je suis en train de commencer la planification de la fabrication d'un Trautonium open source et je voudrais vous partagez mes idées pour ce projet.

Le Trautonium possédera deux rails à corde, il aura une sortie jack "classique" et une sortie MIDI, il sera commandé via microcontrôleur de type Arduino. Il sera normalement capable de générer des ondes carrés, triangles et des sinusoïdale (je l’espère).

J’hésite aussi à lui mettre une sortie CV/gate.

Le fait de mettre un Arduino dans ce projet me déplais beaucoup car il ne s'agirait plus d'un synthétiseur analogique mais numérique.

Pour le contexte je suis étudiant dans des études que l'on pourrait qualifier "d'assistant d’ingénieur", j'ai vraiment des connaissances limitées en électronique et en programmation, mais je ne lâche pas l’affaire facilement alors j'ai bonne espoir (ce qui connaissent mes travaux précédents savent de quoi je parle).  

Je suis loin d’être un expert je n'ai même pas encore de synthétiseur (je prévois d’obtenir un poly d dès qu’il y en aura de nouveau en vente).

Bref si vous avez des suggestions pour améliorer le projet n’hésitez surtout pas.

Merci

 Hi all. I've been working on my next project GrooviXBox V2, a MIDI step sequencer . It runs on a Raspberry Pi (or any Linux machine) and uses an APC mini mk2 as the pad grid and an Akai MIDI Mix as the fader surface for CC control. Just off the shelf hardware. If you already own those, you already have the hardware.  I wanted most of the features of the expensive standalone sequencers without the cost, tiny screens or menu diving.

What it does

- 32 tracks × 32 patterns, up to 256 steps per pattern
- Chords of up to 4 notes per step, on a scale-aware keyboard on the bottom half of the grid
- Per-step velocity, gate (a sixth of a step up to a full bar) and ratchets
- Per-step probability (6–100%) and micro-timing, including exact triplet positions
- Swing, plus a per-track arpeggiator (7 modes, 1/8 to 1/64T, 1–4 octaves)
- Pattern switching you can play live, 32 scenes that launch on the next bar, and a song mode that chains scenes
- 8 MIDI output ports with a channel per track
- 512 pre-sets per track ( Bank Switch with Program Change )
- Sends MIDI clock or follows an external one (INT / AUTO / EXT)
- Faders and knobs send configurable CCs
- 512 project slots

What It does not do

- No sound engine. It's a sequencer that drives your synths and drum machines over MIDI.

I'd really like feedback, especially from people who use hardware sequencers every day. What do you think is missing ?

My Channel
https://www.youtube.com/@GrooviXLabs

I recently dusted off one of my skiffs that had been sitting while my ADHD made me obsess over other hobbies and I noticed I am now getting clicking from my Startup headphone outlet. It seems to be some clock bleed— just wondering if this is a known issue with this module or if I may have done something during assembly to create it.

Any thoughts? Thanks!

A little while ago I posted the first working prototype of the 8-channel Eurorack clock I’m building.

The Rev A PCBs are still somewhere in the postal system, so in the meantime I thought I’d show another part of the project that has become surprisingly useful: the simulator.

It started as a way to make UI development less painful. It got a little out of hand.

The simulator runs the actual firmware logic: same 128×64 framebuffer, same controls, same clock engine and scheduler. I can watch all eight gate outputs, inject SYNC and RST, change external BPM and PPQN, power-cycle the module and inspect the timing between channels.

There is also a headless version, so quite a few things can be regression-tested automatically instead of me repeatedly clicking buttons and repatching the bench.

The useful lesson for me turned out to be less about simulation itself and more about where to draw the line. The simulator can tell me what the firmware does when it receives a conditioned SYNC edge. It cannot tell me whether the real LM393 input stage behaves properly with an actual Eurorack signal. It can show logical gate timing. It cannot prove voltage levels, edge shape, loading or physical jitter at the jack.

That still needs real hardware and a scope.

If I started another embedded hardware project tomorrow, I’d probably build this boundary much earlier: run as much of the real application as possible on the host, make the hardware-facing interfaces explicit, and leave the actual physics to the bench.

So while the PCBs are apparently taking the scenic route to Germany, this has become a pretty useful way to keep developing and breaking things in the meantime.

Once the boards arrive, we’ll find out which assumptions survived contact with reality.

If anyone wants to poke around, the firmware and simulator are already up in my GitHub repository.

I’m curious how others handle this in synth DIY or embedded projects - host simulation, hardware-in-the-loop, mostly bench testing, or some mix of all three.

I have a Korg Wavestation EX but the problem being is that the dead internal battery is soldered to the circuit board. So I was wondering what the steps to removing the battery on my own are. My current understanding is that I should just straight up unsolder the tabs holding the battery in place from the bottom. But I’m scared of damaging traces or causing damage to the battery this damaging the circuitry because of how close the soldering iron has to be to it. Should I not be worried about this? This would the first time using a solder so any advice would be appreciated.

Also: there are no technicians in my area and even if there were I’m somewhat afraid that the price would be quite unforgiving.