MIDI concertina version 2.0 video

[caj]

Sorry for the delay, I was consumed by another musical instrument project and end-of-semester workload.  

Here is a quick recording of my current MIDI construction, using a hall-effect sensor for bellows, and custom boards for the key switches.

 

 

 

[Steve Schulteis]

Wow, that's looking really good. Nice work!

[Owen Anderson]

Amazing work!

[RatFace]

That's looking good.

 

I see you wrote elsewhere: "Right now, my 2.0 bellows sensor has a problem where it doesn't register a change in bellows direction quickly enough, causing extra false notes when I hit a button while changing direction. "

 

I assume (correct me if I'm wrong!) that's because:

1. You're calculating bellows "pressure" as proportional to the displacement, X

2. You've got a spring restores the bellows with a force that's proportional to X

3. That means you can only start a note when reversing the bellows direction by actually moving the bellows a few cm - changing the sign of X.

 

I can see that allowing some actual movement is desirable, but I think the mapping above will not feel right either, because in reality you don't actually need to move the bellows to start a note - you just need to apply pressure. In a real concertina, movement of the bellows is a secondary effect - force is the thing which is primarily manipulated.

 

As a small tweak, you could try including the velocity as well - so your "pressure" is

 

P = a * (X + b * dX/dt) = a * (X + b * V)

 

You've already got a value for a - you might want to try a value of b something like 0.1. This is using the velocity to "predict" the displacement at time b in the future.

 

If b is zero, you'll have what you've got at the moment.

 

As you increase b, then notes will start to "reverse" earlier, and the instrument should start to feel more responsive.

 

If b is too big, then you'll be over-predicting, and it will get twitchy!

 

I'd be interested to hear if this works (should be easy to try!)

 

 

 

 

 

 

 

 

[caj]

Hello,

 

You are absolutely correct that the estimate of the player's force could (should!) include a velocity term like you've described.  In general, we can write the player's instantaneous input force as...

 

(force) =  K*position + S*velocity + M*acceleration

 

...where K is due to the stiffness constant from the springs, S is due to friction, and M is due to the mass being shoved around.  Unfortunately, I have already tried various weighted combinations of these variables, and it doesn't remove this problem entirely.   I think it's due to several unavoidable real-world limitations of the sensor.

 

Fortunately, this bug has little effect when playing with a concertina voice, because it just results in super-short spurious notes that shut off before the synth can do anything with them; however, some instruments like harp or piano will sound those spurious notes no matter how brief they are.  Thus this sensor does not produce an instrument that is suitable for playing in different voices.

 

One solution is to use a force sensor with very little travel, for example the load cell you've used in your bandoneon.  This makes the higher order terms more negligible.  I've designed a few bidirectional force sensors that only have 1-2mm of travel and might try them next.   Another option is to build a position sensor with a long stroke and no springs, and use it to measure the actual bellows extension instead of the player's hand force.

[RogerT]

That's very cool. I'm not a midi fan, but that is very good. Congrats!!

[David Colpitts]

"super-short spurious notes"

 

Aren't these "ornaments?"

 

But seriously, your project looks and sounds great!

[Richard Mellish]

In a real concertina the loudness, and with an Anglo the note, depend on the air pressure difference. The pulling or pushing force you exert on the ends is mainly proportional to that pressure. There is also a component of the force proportional to the masses of the ends and their acceleration when you change direction, but I would expect that to be small.

In a MIDI concertina, if you have a transducer of some sort to sense the force between the ends (as I do in mine) that should very closely mimic the pressure in the real concertina. Such additional force as is needed to accelerate the ends exists in both cases, but I would expect it to be lower in the MIDI one because of the missing mass of reeds and reed frames.

[digver]

That looks great and sounds great as well! I've built several split mechanical keyboards for computer entry from kits so it is fun to see essentially the same thing being used for creating music that's more than the clicking of the keys. As I was listening to your playing I was pondering what switches you are using.

[caj]

22 hours ago, digver said:

That looks great and sounds great as well! I've built several split mechanical keyboards for computer entry from kits so it is fun to see essentially the same thing being used for creating music that's more than the clicking of the keys. As I was listening to your playing I was pondering what switches you are using.

 

The switches are linear cherry red (https://www.adafruit.com/product/5122) that I have soldered directly to the board.  The previous version used a commercially available keypad PCB with sockets, but I've found that sockets are a huge pain in the butt with key switches coming loose as I play.

[digver]

I can see how soldering directly is better for your use case! I prefer low profile choc switches. But they have a rectangular stem, as opposed the square stem on the MX switches that are closer to a concertina's buttons.

[RatFace]

I also used linear keyswitches - gateron reds. I made keycaps with a little flange, which then presses up against a 2mm thick plate containing the key holes (with felt on the bottom). This keeps the switches in place, and it also allows me to reduce the initial travel by adjusting the height of that plate.

[caj]

2 hours ago, RatFace said:

I also used linear keyswitches - gateron reds. I made keycaps with a little flange, which then presses up against a 2mm thick plate containing the key holes (with felt on the bottom). This keeps the switches in place, and it also allows me to reduce the initial travel by adjusting the height of that plate.

 

That looks really sharp.   What do you use to read the matrix of buttons?

 

In our capstone lab, the kids have frequently gravitated to 16-to-1 analog mux chips because they're cheap, you can get them in handy dev board format, they can read analog or digital, and they're super-reliable.  They also eliminate the need for diodes in a button grid, and reduce the number of microcontroller pins needed to read them:  I need four selector pins for the mux, and one more for output to read 16 buttons, and to read for example 64 buttons I need 4+1+4 pins to enable each of four mux boards.

 

For a kit, it would be ideal because a hobbyist can just buy one on amazon, solder the thing to a pin header and solder that to the button circuit board and go.

[caj]

On 6/20/2024 at 12:42 PM, RatFace said:

I see you wrote elsewhere: "Right now, my 2.0 bellows sensor has a problem where it doesn't register a change in bellows direction quickly enough, causing extra false notes when I hit a button while changing direction. "

 

 

Good morning,

 

I'd just like to provide a useful update in case this same problem is vexing anyone else.  I tried tweaking the bellows pressure in various ways to prevent false notes --- again and for context, this is an issue that becomes glaringly obvious with voices like piano or harp, and it happens when I change a button and the bellows direction at the same time.  Either it registers the button first and an E-F# becomes E-D(brief)-F#, or it registers the bellows early and an E-F# becomes E-F(brief)-F#.  Playing the scale on a piano sounds like a cat is running across the keyboard.

 

Anyway, I tried updating the bellows pressure formula including your suggestions, and then some other desperate attempts like witholding a "Note On" message if the bellows pressure is dropping too quickly.  None of that seemed to help.

 

Then it occurred to me that I was neglecting the buttons, which go ON before they are all the way down.  Maybe my fingers just weren't creating an appropriate gap in timing between the first button OFF and the second button ON; or maybe even worse, they could overlap.

 

So what I did was saturate asymmetrically.  The buttons already have saturating counters for debouncing purposes.  The counter is incremented or decremented by 1 every millisecond until it either rises to a DEBOUNCE threshold to be considered on, or drops to 0 to be switched off.  I updated the code so that it increments by 1 and decrements by a larger stride; right now DEBOUNCE=50, and the stride is 13.  This does better than anything else to make the problem go away.

 

[RatFace]

I think I disabled debouncing entirely. I did that in two stages:

 

I first made it so that rather than delaying registering a press, I made it so that pressing was immediate, but releasing was delayed (i.e. making the debounce happen at the end of the press, not the start). That eliminated the additional latency (which is terrible for music!).

 

That's fine, but it means playing repeated notes is mushy...

 

So I reduced the debounce time at the end of the press until repeated notes were good, without causing problems...

 

... and that time is zero!

 

In fact, when you look at the response chart, you can see that there's hysteresis in the key anyway, and that appears to be enough to prevent bouncing. Even if I try, by holding the key part way down, then I don't get jitter in the note.

 

https://www.gateron.co/products/gateron-silent-switch-set?variant=40036318740569

 

You can see that after pressing the key, it needs to lift by 0.25mm or so to release, and this seems to be perfect for preventing bouncing. 

 

It's a good feeling when you can make code by better by only pressing the delete key!

Edited August 16 by RatFace

[RatFace]

Oh - but I see yours are Cherry Reds:

• Type Linear
• Operating force: 45 gf (+/-10 gf)
• Pretravel: 1.8 mm (+/- 0.3 mm)
• Total travel: 3.6 mm (+/- 0.3 mm)
• Reset point: 1.8 mm

which don't seem to have that hysteresis, so I can see why you'd need to debounce them. I do recommend the Gateron ones!

 

[caj]

Honestly, I'm not sure how much debounce I actually needed.  I just threw it in for good measure, and now I am using them entirely to affect the switch timing by ensuring an asymmetric delay.  The tentative settings are pretty extreme:  50ms to switch on, and 4ms to turn off.

 

Previously I hadn't considered any delay time on the buttons because it sounds like such a bad idea; but what I didn't realize was that the player may expect a note to fire when the button hits the ground, and a delay can compensate for an early ON.

 

I'll try those Gateron ones; I hadn't thought of using silent buttons, but it makes a lot more sense given how much we want to suppress mechanical noise.

[RatFace]

I think a real concertina starts speaking immediately the buttons starts going down - so I'd be inclined to trigger the note as soon as possible to emulate that (especially as key switches only trigger after a few mm travel anyway).

 

The other thing is that there will inevitably be delay in the system anyway - through processing on the microprocessor, and then in conversion from midi to audio. I suspect that delay is more than you want anyway, and you wouldn't want to add any more.

 

I play mine through my phone (Pixel 3a) into speakers/headphones, and the processing delay isn't noticeable. However, if I use my tablet (Galaxy Tab S7 FE), the latency is awful (though I didn't notice it at the beginning when I could really play yet). I think if you made an instrument that speaks too quickly (i.e. faster than a real concertina), then that's massively better than going the other way and running the risk of adding too much latency...