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
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.
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.
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 https://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.
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.
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.
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.
@normandc Yeah it is! I did change the default background but for whatever reason it wasn't working for me, so I changed it back.
The 14 year old version of the CAD software we used up to last October had a light blue background by default. The newer version has an almost white one. I've gotten used to it, and switched FreeCAD to a similar background. I dislike dark themes and backgrounds.
- Tooted on Mastodon's default dark UI 😉
@normandc On my work Solidworks I go for a mid grey background, and a macro that toggles it to white for taking screenshots. Mid grey didn't work so well in FreeCAD because it's too close to the default part colour!
@piggo They're the footprint for the sensor, so I can just have the legs sticking through and solder some stripboard on the outside.
@gbrnt I'm glad I'm not the only one who still used Audacity... I was told it was outdated, but it's the only workstation that makes sense to me
@gbrnt Mostly GarageBand and other free DAW's, but none of them make any sense to me, not like Audacity makes sense to me.
@evandornbusch Yeah it seems a bit complicated to use a DAW for quick audio recordings and stuff. I am using LMMS for the MIDI side of this though.
@gbrnt I'd agree. What kind of sounds or music do you make? I've been making notification sounds I want to get onto some PinePhone OS's.
@evandornbusch I've done notification sounds in the past, and occasionally edited the audio track of videos (noise reduction, adding music, etc). It's just my go-to program for any kind of audio editing or recording.
In this case it was the first thing I thought of for measuring the timing of the key going down vs the sound coming out of the computer.
@gbrnt I don't suppose you could let me check our your favorite self-made notification sound for some inspiration? All of mine involve chirps in the several kHz tone and I've been told they're very unappealing to the average person.
@evandornbusch Sorry, I never managed to come up with something I liked much! The best I've got is a ding sound in my pomodoro timer: https://github.com/gbrnt/pomodoro.py/blob/master/timer_done.wav
@gbrnt I think it's lovely! I am creating a collection of tones and sounds if you ever need one for an open source project.
@evandornbusch Now I think about it I might not even have made that sound! It might have been from freesound.org. I remember trying to make a good ding sound but not whether I managed it.
@gbrnt I would like to offer up my dings for any future projects you may have: https://drive.google.com/drive/folders/1nE7y9TrQn2IoWsYPzqwa-F8iS9TJaE7J
@evandornbusch I used to play the sax but it's too loud for me to not feel awkward getting back into it, now that I have a lot of neighbours. So the electrosax is a nice way of practicing quietly.
@evandornbusch Yep, with the "Fluidsynth MIDI Synthesizer" app. The first soundfont I tried didn't respond to breath pressure so I'm looking for one that does.
@gbrnt I have a Soundbrenner Core I am working on getting to beat to the beat of music. This helps me understand the bluetooth MIDI pathway.
@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 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)
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
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!