I like the idea of making a DIY midi saxophone. Just a very basic one to make some noise

I'm guessing the hard part is measuring the breath. You could measure pressure, but if you're simulating a real sax it would have air passing straight through. I'm not sure the pressure would change much?

I added a basic breath sensor to the pastry saxophone. It kinda works! The response of the breath sensor is quite slow - I think I need to use something stretchier than a nitrile glove. It doesn't feel sensitive enough to do staccato notes or anything yet.

I didn't get dynamics working with the USB MIDI yet, but on/off breath control works well

The breath sensor works like this guy's video: youtube.com/watch?v=es92GqYBge

The black tape all over it is to block out light - I found it was making a big difference to the readings.

Some quick sketches for a 3D-printed version of the mouthpiece. I can sandwich a membrane between two halves and make the whole thing a lot smaller.

The volume of air inside is smaller, and I'm hoping that means that the response to changes in pressure will be faster, enabling me to do quick staccato stuff.

Here's a first draft of the mouthpiece half - this should work ok. The other half with the sensor should be quite simple and can wait until tomorrow.

I've started printing the mouthpiece and designed the sensor half of the breath sensor. This uses a TCRT5000 IR reflectivity sensor, which shines at a diaphragm clamped between the two halves.

When you blow into the mouthpiece, the diaphragm expands towards the sensor, increasing the amount of IR that's reflected back into it.

Aaaand version 1 of the electro-sax mouthpiece is sort of assembled! It seems like it'll work but I won't be able to test it until the actual sensor arrives at the end of the week.

Electro-sax is just a way cooler name than midi sax

Dynamics now work! I'm using the breath velocity value from the cardboard breath sensor to set the MIDI breath controller value, and mapping that to volume in the synth. I'm sure there's a much more complex and nice-sounding config that can be done, but this is cool!

It needs to be a bit more linear, but that just means making some sort of calibration curve for the sensor. That can wait until I've got the 3D printed one working.

I've put the code up on gitlab.com/gbrnt/electro-sax

There's currently a latency problem - I need to check whether it's on the Arduino end or on the computer end. The breath sensor has some extra latency - I think that comes from the current prototype but I'm not entirely sure.

The end-to-end latency of the electro-sax is definitely too high right now. It's recommended to get it below 10ms (if you can) and here it is at 160ms.

That's enough that when you're doing something like a run of short notes you do one too many because the sound hasn't caught up yet.

Let's see how much I can improve this just by changing Jack settings. Not sure how Pipewire comes into this.

I got a MIDI app on my phone and connected the electro-sax with a USB OTG cable - the latency is much lower! It's definitely low enough to be fun to play now.

So that means I have to delve into linux audio again. I might just revert from Pipewire back to Pulseaudio just to see what effect it has.

So far in my attempts to improve the sensitivity of my breath sensor, I've managed to make it worse.

The first cardboard prototype had a range of 0.38V, or 77 counts in an Arduino's 10-bit ADC. Ideally it'd be more than 127 for a completely step-free MIDI reading.

The 3D printed prototype got me 18 with the nitrile glove membrane, or 31 with a white balloon. Not great. Hopefully the sensor I designed it for will arrive tomorrow and I'll be able to try it out.

I also got a BMP280 pressure sensor, which should be able to be polled fast enough to get useful readings. That might be an avenue worth pursuing as it can be in quite a small chamber!

Follow

Hmm, not doing great with the BMP280 pressure sensor. It works really nicely for detecting a change in pressure, but it doesn't seem to be very good at going back to its original zero point.

So in the screenshot you can see the lows are at different points each time I stop blowing. I assume it's doing something clever, but whatever it is it makes it less useful to me.

· · Web · 5 · 0 · 1

The best breath sensor I've built is still the original LDR-based one, with a difference between "not blowing" and "blowing hard" of 77 counts.

I could tell that its response was slow, though. So now I've measured it!

Going from LED off to on, the response time is 30ms. From on to off it's 100ms. Luckily that's the ok way round, and normally it won't be varying by so much.

I'd like it to be faster but it's probably an ok solution for now.

Time for a slightly more scientific test of the TCRT5000 based solution. This is the reflective IR sensor with an IR LED and phototransistor.

So far it looks like I can make this good enough by correctly setting the distance between balloon and sensor, and the LED brightness.

I might also test the effect of changing the (current limiting?) resistor next to the transistor, because I've never really got my head round transistors.

It looks like I found the sweet spot for this sensor. With this setup it's 14-16mm from the membrane. My measurement of the distance is bad so I'll still need some adjustability.

I found it was best to set the current-limiting resistor for the LED so that the "non-blowing" voltage was about 4V - maximising the sensitivity.

Not sure why the distances needed in the datasheet are shorter than mine - they're using a mirror to reflect the beam so I'd expect it to be longer.

I tried changing the resistor on the phototransistor and it didn't have much obvious effect on the max breath sensitivity, so I'll probably leave it at the original 4.7K.

The electro-sax now has transposing! You press a key combination to activate transpose mode, and then play the key you want to transpose to. So if I want to play alto sax music in the right key, I play Eb and then press the octave key to lock it in. It seems to work well!

It needs a few octave keys so it can play in the correct octave, but that's fine for now - an octave off is still better than attempting to tranpose in my head.

The electro-sax sensor distance tester looks pretty cool. This will let me vary the distance between the membrane and sensor in a more controllable and measurable way than my cardboard prototype.

Look mum, I did a science!

This is using the new sensor distance tester. It made it so much easier to do this experiment properly.

It looks like my previous conclusion was about right - 13-15mm between sensor base and membrane is about the right distance.

The good news is that with that distance, I get a range of ~270 ADC counts between "not blowing" and "blowing as hard as possible". That's great - it can easily be mapped into MIDI's 127 breath velocity values.

Here's the new breath sensor design mounted to the electro-sax cardboard prototype. It's a lot nicer to play! I can do staccato notes now!

Latency continues to be a problem on my computer, but at least I can be sure it's not on the Arduino, as it works fine with my phone.

I tried switching back to Pulseaudio (from Pipewire) to see if that would reduce the MIDI/audio latency I'm seeing with the electro-sax. Haven't measured it yet but it doesn't seem like it made much of a difference.

Hopefully that's an indication that it's not on the (complicated) audio side and instead on the (slightly simpler) MIDI side. Better not be something fucky with USB.

Just to compare audio latency, I'm trying out a live USB of Ubuntu Studio. It looks like without doing anything, that cuts my latency from 150ms to 93ms. And changing my headphones to my front panel output instead of my USB DAC cuts it further to 24ms.

That's still not amazing, but it's a world of difference from being unable to play properly.

Switched back to the Arch install and changed headphones to the front panel output instead of the DAC. I got ~60ms latency. Still playable.

So why is the Audioquest Dragonfly's latency so bad?

Some more progress on the updated breath sensor. It's still quite bulky, but at least with the longer mouthpiece I won't be bumping my nose into it!

Will try this for a while before deciding whether it needs a fake reed - the positioning of the air inlet might be enough to make it feel close enough to a real sax.

The sensor holder is supposed to stay clipped to the body of the sax, while the rest can be unclipped for cleaning.

The actual clips are not very well designed for 3D printing in terms of layer orientation, so we'll have to see how that goes. They may not be very durable.

Ok that didn't last long!

Might just make it screw on instead in the next version because that's easy

There's something weird going on with the new sensor - when blowing gently the reading from the sensor actually goes down!

Here's a graph of the readings as I gradually increase from not blowing to full speed. It dips down at the start. That's not good!

I'm guessing it's because I added a slight "bypass" between inlet and outlet, and the flowing air has a lower pressure that actually pulls the balloon towards it.

For reference, here's the previous sensor. You can see because the air *must* move the balloon to flow from inlet to outlet, there's a significant jump when I start blowing.

I think that's the better way to go!

Show newer
@gbrnt If you leave it for 8 hours, does it level out at a certain point?

@sj_zero Probably, even in a few minutes I can see it leveling out. The problem is I was hoping to use it to detect whether to play a note or not, and that's hard when the baseline keeps changing.

@gbrnt I'm just wondering if the issue has to do with it being a brand new sensor and if you cycled it a few hundred times it might mellow out.

@sj_zero Huh that might be worth a try! I'll leave it connected and test it again tonight

@gbrnt Seems like it would be usably accurate only if the air pressure changes happen at strictly regular instances.

@AskChip Which isn't likely when using it as an instrument! I'm sure there's some software magic that could be done to handle the changing baseline, but I don't feel like doing it!

@gbrnt It looks very much like the result of a leak somewhere. the waveforms all drift up when low, and down when high for any period of time.

@AskChip There's an intentional leak, the chamber is essentially a tube with a flow restriction at the outlet. So when I stop blowing it should always be the same pressure inside (ignoring atmospheric pressure variations)

@gbrnt
perhaps the pressure exceeds the 1.1 bar maximum of the sensor, and that's throwing it off somehow?

@till I *think* the values on the graph are millibars so that's not happening, but I could be wrong there.

@gbrnt Based on the graph, any blowing at all is vastly more pressure than the baseline, so it should be easy to programmatically compensate for the sensor drift.

@yngmar It's easy when you're doing on/off blowing like I was in the graph, but I'm guessing it's harder when you're trying to play a piece of music with dynamics

@yngmar Blowing softly just looks like the sensor is gradually drifting upward

@gbrnt How did you get the pressure sensor to behave?

@sj_zero I didn't! This is a more mechanically complex version that's based on your breath flexing a diaphragm. It uses an IR reflectivity sensor to measure the distance to the diaphragm and thus how hard you're blowing.

@gbrnt Ah, ok! Sometimes it's hard to fault old mechanical ways.

@sj_zero Yeah, this is one style that Jeppe from Kontinuum Lab on youtube uses, so it's somewhat tried and true.

I was a bit worried about protecting the sensor from the breath moisture anyway, so the electrical simplicity of this is quite nice! Downside is that it's much bulkier.

@fortifieduniverse Haha yeah I'm not in any rush to make a "proper" version!

@gbrnt you could just change the box you're using based on your mood. today it's pastries, tomorrow it's a pasta box. 😃

@gbrnt
Good luck! Tricky...

Discovered elk.audio/ the other day, don't know if it fits your use case and haven't tested. They advertise low latency.

@arthurlutzim Looks cool! I only see an image for raspberry pi though - is there an x86 one I'm missing?

@gbrnt
I think they focus their efforts of kernel patching on a few platforms, not sure x86 is one of them

@gbrnt USB protocol overhead vs. built-in being right on the PCI bus?

@ieure 100ms difference is a lot though! I bet it's something you can configure some things to minimise but it's way over my head

@gbrnt Looks like you made a snap on that part, correct?

@gudenau Yeah, it was supposed to snap *on* and instead it just snapped.

Show newer
Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!