Cybrid - a DIY MIDI controller with grand piano action

n-player Yeah maybe, but isn't this all without velocity?

HZPiano that is why in digital pianos 3 sensors instead of two

Is that for calculating velocity, even when the key has not been fully released?

AlexanderBunt When I have more time I will try to check your circuitry, I found one image of an earlier prototype with Arduino instead of Teensy which might be helpful for the wiring:

Also, I remember with the Teensy there were some stuff you had to enable in the Teensyduino for it to work properly, maybe the serial communication needs a specific configuration?

BTW, do your potentiometers have three connectors on the other side (not visible in the picture)? Because I see they have three on the visible side and you use only the middle one. Mine have two connectors on the left and one (middle) on the right.

AlexanderBunt Exactly that.

(And, in a well implemented (virtual) piano, this makes restriking the 'string' possible without it being dampened first. Raising the key to the full-up position also means the damper is then fully back on the string).

Cheers,

HZ

AlexanderBunt There may be sensors and upstream controllers that have velocity for broader applications.

CyberGene Yeah, three on one side and two on the other side… can that be a problem?

EDIT: Hm I thing there is the problem. I used Rotary Encoders… that's not the way how its is meant to be, I think…

I just bought a few 10kΩ cermet potmeters, which will arrive after the weekend, so I will try again then. Like I said before… I am just starting in this 'world'… ;-)

AlexanderBunt Rotary Encoders

Ah! There's your culprit.

Cheers and a happy learning curve,

HZ

HZPiano Thank you! There will be many moments of learning during this project, I think. But that's a good thing!

HZPiano And, in a well implemented (virtual) piano, this makes restriking the 'string' possible without it being dampened first.

Yeah I understand that part, but on a carillon, there are no dampeners. Do I still need three 'measure points', or just two?

AlexanderBunt Three sensors (with strategic placement in the key travel to allow the restrike without having to go all the way back to the top, and still have velocity information between the en-route and lower sensors) at least.

Or have optical/magnetic position sensors which, with nifty programming, can do a lot more nuanced things than "just" three sensors. But there, my insights are theoretical rather than practical, but some great people here know a lot more about that.

Cheers and best,

HZ

@AlexanderBunt Ah, doing a carillon is an interestingly different technical challenge.

Some of the key differences I see from doing a piano:

1. Physically quite a bit larger per-note. Both the overall structure, and the individual keys. You have space to put things wherever you want, and to make keys that feel right you're going to end up with long, thick pieces of wood.
2. You have fewer notes; presumably a max of 77, that being the largest real carillon?
3. Your keys only do one interesting thing; they trigger the mechanism which strikes the bell. They don't then dampen it later. Right?
4. Everything is made from scratch; you're not interested in pulling unused carillon consoles out and converting them?

But you still need to measure the instantaneous velocity as the key passes some triggering point?

I don't think using optical reflectance to measure distance is at all appropriate for you. That'll be a pain, and there's no reason you need to constrain yourself with physically small sensors.

My initial thoughts for you would be to use rotary encoders that can attach to existing shafts, like these https://www.cuidevices.com/catalog/motion/rotary-encoders and then measure the angular velocity at the shaft. You'll get clean values which directly correspond to physical motion you can understand. They're expensive, probably starting at $20/ea, likely more with limited availability of everything these days. But it might be possible to connect all the ones you'd need to a single sufficiently powerful microcontroller. That'd make your life quite a bit easier. But some design work, reviewing the interfaces available on those encoders, would be necessary.

Similarly, you could adapt some sort of fine-resolution rotary encoder like you already accidentally purchased to the task.

I'd shy away from potentiometers, if nothing else because you'd need to get a huge number of ADC channels and that is more of a pain in the ass than the casual observer realizes.

You could also apply optical reflectance sensors as they were originally intended to be used. Point one at the side of every key, and put a strip of alternating black and white lines on the key, such that as the key moves the sensor will swing between its minimum and maximum outputs. That'll get you a pulse train proportional to speed. You'd need a tiny bit of clean up on the signal and then it could go straight into a microcontroller. You could almost certainly get away with feeding 77 such signals into a single sufficiently powerful controller.

JayKominek So enough to think about…

To be clear: I don't have to build the console by myself. I bought a practice console with no bells attached, so I only need to do the electronics… And also, I just have 52 keys I think. That's making things easier.

I like the last idea you got. I think there is enough space to do this. So for my concern: you mean putting a CNY70 for example at the side of a key, and then a strip of (for example 2 black and 2 white) stipes on the side of the key. Then measure the time between the sensor switching from black(far) to white(close).

I think there is also a sensor needed which registers that the key 'hits' the bell, to give the 'note on' signal. That combined with the velocity of the sensor at the side of the key will be a solution maybe. But then, you need a double of inputs (104)… and thats too much for a regular board.

And what do you think about pressure sensors, like the FSR402? My concern with these things are that they won't last long, cince there are many hits on them. But maybe this will work very nice; No need to worry about travel distance from the key here…

A last thing to keep in mind: the amount of keys that is pressed at the same time is not so big as in a piano or organ. Maybe like 5 keys at the same time max. But the reaction speed needs to be very quick.

Would like to hear your ideas on these things!

RIP (I asked estimate to about 10 different companies/technicians and all gave similar price range and similar explanations at my balking)

6k$ ?

MrGr Del Vento (I asked estimate to about 10 different companies/technicians and all gave similar price range and similar explanations at my balking)

6k$ ?

Are you asking me the price range? If so, yes, you got it right, that was in right the range.

AlexanderBunt And what do you think about pressure sensors, like the FSR402? My concern with these things are that they won't last long, cince there are many hits on them. But maybe this will work very nice; No need to worry about travel distance from the key here…

I would not use them for the same concern you stated but that's just me. After all also LED have a finished life, so even "our" sensors may degrade and die with time.

AlexanderBunt I like the last idea you got. I think there is enough space to do this. So for my concern: you mean putting a CNY70 for example at the side of a key, and then a strip of (for example 2 black and 2 white) stipes on the side of the key. Then measure the time between the sensor switching from black(far) to white(close).

I think there is also a sensor needed which registers that the key 'hits' the bell, to give the 'note on' signal. That combined with the velocity of the sensor at the side of the key will be a solution maybe. But then, you need a double of inputs (104)… and thats too much for a regular board.

It obviously depends on how much you want to design on your own versus as much you want to reuse from someone else. If you are not too much opposed in the latter, I believe your best bet is one of the things that Jay, stem_piano or I are doing (with the help of many others who AFAIK are not getting into the hw yet). Once you use these sensors to detect the position (of hammer or key in the piano's case) you can do many things with just one sensor per key. Note: this is different from what CG did with the comparators, which basically used the optical sensors as fancy touchless switches.

Also you may want to check for inspiration wrt what others do by lurking https://www.kvraudio.com/forum/viewforum.php?f=180 -- I don't think there is anything super-exciting for this purpose there, but that's with the lens of my interest, not yours.

Well, it's a pretty dull post, sorry that's the best I can do in between commits to my own repo 🙂

The real question is:

Is Your Cybrid Safe From Supermaneuverable Air-Defense Fighter Aircraft?

(can we call this type of comedy "postmodern"? 🤣)

RIP I've been thinking it over, and I think the best way for me to do this is to use one CNY70 sensor under each key. Cince I don't need to send a 'note-off' signal, the most realistic method is to let this one sensor capture the moment when the key is, lets say 1cm, above the bottom of the shaft (above hitting the bell) and then capture the moment when the key is ca. 0cm from the bottom of the shaft (and thus on the point of hitting the bell). Then calculate the time between this two points for the velocity, while sending a note-on signal when the key is at 0cm (hitting point).

So in short, use the method of CyberGene, with only two points of measurement, which will simplify the physical structure and also the code.

To be clear:

1. Key is being pressed.
2. Key passed first point (1cm from bottom): set time of first point.
3. Key hits bottom(at 0cm): set time of second point.
4. Calculate time between first and second point -> velocity.
5. Send note-on with velocity to computer software.

I think this will give the most realistic result, because many times, the carillonneur will leave his hand on a key (leaving it in the middle) before pressing the key again, but mostly at a different speed as the time before. Also, when he makes a tremolo, he leaves the key just a tiny bit (thats why I said 1cm but it can be less) above the bottom of the shaft and pressing the key quickly a few times. So between each note he lifts the key maybe 1 or 2 cm when he plays a tremolo. And with different velocity of course.

Curious what you think about this.

And why JayKominek should I stay away from potentiometers? I don't see the point that it will use many ADC channels. As I see it, @CyberGene did also use potentiometers, but used just one ADC channel per key… Cince I have but 52 keys, this won't be a problem…

As I said, I would love to hear what you think about this.

AlexanderBunt So in short, use the method of CyberGene, with only two points of measurement, which will simplify the physical structure and also the code.

and

AlexanderBunt should I stay away from potentiometers?

Because they are extremely tedious to install and regulate?

The non-potentiometric only-two-measure-point code is extremely simple:

https://github.com/davidedelvento/Mybrid/blob/main/RaspberryPiPico/pico-piano.c#L355-L393

Also, with this approach you can have the distance adjustment in software as I do in https://github.com/davidedelvento/Mybrid/blob/main/RaspberryPiPico/pico-piano.c#L521-L560 so you can have a number of settings, perhaps for testing and/or for different kind of music. Good luck re-regulating all the potentiometers with a screwdriver….

Alternatively you can use a DAC instead, which will be similar to what @CyberGene did but in software. I have not thought too much about it, besides that you need one DAC channel per key or a fast multiplexed one. That might work well too.

AlexanderBunt Curious what you think about this.

I think that electronically and as far as code is concerned this sounds very close, if not identical, to what we are doing for pianos.

RIP Okey, this sounds good. If it is possible to do two measure points without potentiometers, that would be better of course. I didn't know this was possible, so thanks for the advice!

I think that is what I will do then. Use one sensor per key, and adjust the measure points in code. I see you did this with a Raspberry Pi, but do you think it's also possible with for example a Teensy 3.5 of Arduino Mega (calculating speed etc.)?