RatFace

Thanks. Yes, they sound nice together. I did cheat slightly in the recording/mixing by boosting the guitar mic slightly - the live sound had an acceptable balance (I believe), but I would have preferred the concertina to be a little quieter. Me too! I am part way through transcribing the parts in the vain hope that if they're easier to read they'll be easier to play. The edition that I have (emailed to me) has got pencil markings (fingerings etc) all the way through suggesting the previous owner had made a serious attempt to learn/play it. On the cover there are two stamps: Presumably the crossing-out indicates that it passed from Mellor to Maddocks. Harold Mellor gets mentioned here: https://concertina.org/wordpress/wp-content/uploads/2021/01/PICA-Volume-4-2007.pdf and it appears that c.net member @Gerard owns his concertina: and HC Maddocks here: https://concertinamuseum.com/NC50201-003.htm I don't know which one of these two was responsible for the pencil marks...

This is a really pretty piece, and sounds lovely. A splendid concertina too! I did nearly give me kittens though: I had just uploaded my "Andantino" when I saw the title page of yours pop up as I finished test-watching mine and I thought you'd gone and beaten me to it!

I had been corresponding with Scottish guitarist Stewart Kelly about music by Regondi, and then we realised he was due to give a concert down here in Oxford, so we decided to play a piece by Regondi together:

Yes - exactly! There are USB splitters (into headphone + usb), but I suspect the usb side is then for charging only: Maybe another option would be to use a small USB hub (one in from the phone, two out)... I have no idea if it will work. Though perhaps I can try with my current phone. Apologies for the thread drift

I really like having the instrument completely stand-alone - so no need for external power or devices, and wired headphones are not at all inconvenient. I clip my phone on the top - it takes in the midi, gives me far more control over the audio generation than I really need(!), and also powers the microprocessor over USB (with the phone display off, it will last a few hours). Then I have a little battery powered amp/speaker system. I took it on a train journey recently, and had an hour or so to kill at Basingstoke, so was able to play (silently) on the station platform. I didn't even get arrested! I do have a problem/question about that though - a lot of newer phones don't have a headphone socket, so I'm unsure how to do this on a phone that only has USB. I need the USB to power the Arduino/Teensy, and receive midi, and output to wired headphones. Does anybody know if that's possible (or suggest an alternative - I quite fancy getting a new(ish) Pixel, but this is stopping me!)?

Yes - typically the chain is something like: The keys will be wired to A programmable microprocessor - Arduino. This reads the keys (but often has to do it by scanning the keyboard, wired as a "matrix", which can take some time). It will also read things like a pressure/force sensor, which will have a clock (typically 80Hz). On mine, the processor completes its loop 80 times a second - so that's 12ms latency straight away! The microprocessor sends out midi: That might go direct into a hardware midi expander box. I expect this results in the lowest latency, but I don't know/think any/many allow for custom soundfonts Alternatively, it might go to an external computer/phone over USB (fraction of a ms) which is converting the midi into an audio signal. Audio Evolution Mobile Studio on my phone - it has custom drivers to reduce latency, and supports custom soundfonts and effects etc. I don't know what people use if they plug into a PC. I think some people do this using something like a raspberry pi inside the instrument - which is basically the same thing. Alternatively, you could synthesize the audio on the microprocessor (avoiding midi altogether)- either by writing code to load/play soundfonts, or by just building the audio out of a truncated fourier series. I quite fancy doing the latter - the sound wouldn't be "real", but it would be very convenient (no external computer/phone needed), and you could still send out midi for recording etc. Then the audio signal will go straight to wired headphones/amp+speakers. Bluetooth has a minimum of 40ms, which is a lot. There may be other ways of doing things.

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...

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!

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!

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'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!)

Though the natural conclusion is that one should try to avoid situations where control is necessary! It occurred to me some time ago (about the time my daughter turned from a child to teenager!), that with children we have a huge amount of influence and almost no control (not in the long term, anyway). Perhaps the same should be true for musical instruments!

Yes - though if one wanted to measure attack (velocity), the Melodicade MX project has a nice setup using pairs of switches and timing (but that is again different to after-touch pressure) I think it was here on c.net, in another thread, that somebody wisely commented that every thing that can be controlled must be controlled. The point being that, beyond a certain point, the problems of having too much to control outweigh the advantages. In most instruments there is a trade-off between complexity and expression. For example, the way that the piano plays a note according to the strike velocity, and then the note decays away exponentially with the only remaining control being a simple "on/off", is far more "liberating" than it is limiting.

RAc: I think that you're proposing to use the bellows movement speed in an electronic concertina as a model of the air flow through a real concertina reed. That would work fine... apart from a few problems(!): 1. You'd need to emulate/model other aspects too - for example, you'd need to have valves that would open up (presumably via servos etc) as you press the buttons as otherwise there would never be any bellows movement anyway. That would be tricky - as the system would have to be extremely fast in order to avoid latency. 2. OR if you just had permanently leaky bellows, that resulted in movement proportional to the applied bellows force, then the more leaky they are (and thus the easier the distance measurement), then the less like a real instrument it would feel. 3. In either case, how do you measure the bellows opening "distance" when they can bend (ends not staying parallel)? And if you stopped them bending, it wouldn't feel right. There is a way to measure the speed at which the bellows open/close - and that is the flow rate through a valve. That would probably be more effective than any mechanical measurement as it would handle the bending... but you'd still have the first two problems above: 1. A complex system of valves (one or many) linked to the buttons, with a flow rate sensor. All the servos and the flow rate sensor need to be really fast in order to get a low latency (a few ms) - so as you press a button, the microprocessor needs to control the servo to open the valve. It also starts playing the note, but at this point the flow rate is zero, so it's zero volume. The flow sensor will then start to measure the airflow, and report it back to the processor, which increases the volume. And all that needs to happen within a few ms, or the instrument will feel laggy. 2. A leaky-bellows system, where the flow rate is just a proxy for pressure. Now the microprocessor can measure the applied force is happening even before the button is pressed, so the latency problems are reduced... unless you're reversing the bellows direction (relevant for Anglos). But it won't feel like a real concertina... So I think method 1 is theoretically sound (maybe even superior), but impractical. And method 2 is effectively just measuring the pressure using a flow rate sensor as a proxy. I think the result is that you'd be better off just measuring the pressure or force directly!

Yes, load cells in parallel with each other, but in series with the bellows!