Hello!
Commercial implementations:
* https://www.qrsmusic.com/PNOScan.php
* https://www.bechstein-digital.com/de/vario-connect/
* Yamaha AvantGrand series
* Kawai Novus NV series
DIY implementation:
* http://forum.pianoworld.com/ubbthre...y-hybrid-midi-controller-is-finally-here.html
I'm looking for contactless sensors, not necessarily optical ones. Hall sensors would be okay unless they impact the mechanical behavior of the keys through magnetic force in a remotely significant way.
There seem to be two general categories of sensors:
* light barriers, typically on hammer/hammer shank: (all except PNOscan?) fixed length results in good speed measurement uniformly across keys (if assembled precisely). Position fixes the trigger point. Position, length and measurement setup must be very precise to have uniform response across all keys. I guess that makes it difficult for DIY projects. You could let the PCBs get produced very precisely (I guess, though I'd also wager that that would also be very pricey), but putting the light barrier elements on top of the hammer/hammer shank or below the key would have to be done manually.
* gray sensors (on hammer shank (DIY Cybrid), below keys (PNOscan)): calibration (PNOscan) is done through a special procedure where you hold down each key until acknowledged by the system. In that way the system (AFAIK) knows the up and down positions of each key in terms of sensor output values. It seems that the strike/trigger point, and points that are used to measure "speed", are set somewhat abstractly because there is (AFAIK) no simple linear correlation between sensor output and key position. (Btw: if someone knows these PNOscan boards, what sensors are they using? Brand? Part number?)
I was also thinking about hall sensors. They would be a little bit more resistant against dust settling below the keys. I wonder if they'd noticeably affect the mechanical resistance/inertia/behavior of the key?
What sensors/sensor setups would you recommend?
How about linear encoders? I guess the price would be prohibitive if taken times 88?
Are there ready-made sensors that use a movable part with variable translucency? I think the AvantGrand is using something akin to that as a second, additional sensor row below the keys to transmit key positions continuously.
Other ideas?
The minimum time delta to measure speed/velocity is around 0.3ms. Let's assume 0.1ms to be on the safe side. That should result in 127 MIDI velocities (at least, MIDI 2.0 supports more), and the sensor setup should be able to reliably produce those velocities with a variation no more than +/-1. Next question would probably be: is this a linear transformation? ie. 0.1ms -> 127, 0.2ms -> 126, etc.? If taken verbally, it should imply taking the inverse because of how speed is defined: v=s/t -> t=s/v where s is a fixed length of nonphysical units. For 0.1ms and 127 we get s=v*t=12.7 "ms". For v=126 we get t=12.7 "ms"/126 = 0.1008ms. So, the most extreme case requires a resolution of sub 1 microsecond, even a bit lower if we consider that we are actually measuring two times and this is really a time delta.
What are the capabilities of the various sensors mentioned (and not mentioned)? Is a gray sensor capable of delivering such a time resolution?
Next question is: how to feed those 88 sensors into a ADC/processor to evaluate the data on-the-fly and put out the MIDI events? Using an ADC or even a global ADC is probably prohibitive considering the sub microsecond resolution requirement. The DIY solution by Cybergene has trim pots on the gray sensors to set the levels between which to measure the time delta (AFAIK). It's probably necessary to go down a similar route, though I would have preferred to feed all gray sensors into a single ADC in order to have maximum post-processing freedom in software.
All comments and thoughts welcome.
TY!
p.s. the Bechstein digital system claims a scan rate of 20 kHz. According to my own calculations they should have a hard time reliably identifying a lot of the higher velocites if they use it to identify the time delta between two fixed sensor values. Maybe they are doing it differently? Maybe they evaluate the slope of the continuous measurement points or some other sort of data aggregation? But that then makes me wonder whether they are actually measuring something that's not really corresponding to the speed at a sensible trigger/strike point but is more like a washed out/average measurement over a longer movement?
Commercial implementations:
* https://www.qrsmusic.com/PNOScan.php
* https://www.bechstein-digital.com/de/vario-connect/
* Yamaha AvantGrand series
* Kawai Novus NV series
DIY implementation:
* http://forum.pianoworld.com/ubbthre...y-hybrid-midi-controller-is-finally-here.html
I'm looking for contactless sensors, not necessarily optical ones. Hall sensors would be okay unless they impact the mechanical behavior of the keys through magnetic force in a remotely significant way.
There seem to be two general categories of sensors:
* light barriers, typically on hammer/hammer shank: (all except PNOscan?) fixed length results in good speed measurement uniformly across keys (if assembled precisely). Position fixes the trigger point. Position, length and measurement setup must be very precise to have uniform response across all keys. I guess that makes it difficult for DIY projects. You could let the PCBs get produced very precisely (I guess, though I'd also wager that that would also be very pricey), but putting the light barrier elements on top of the hammer/hammer shank or below the key would have to be done manually.
* gray sensors (on hammer shank (DIY Cybrid), below keys (PNOscan)): calibration (PNOscan) is done through a special procedure where you hold down each key until acknowledged by the system. In that way the system (AFAIK) knows the up and down positions of each key in terms of sensor output values. It seems that the strike/trigger point, and points that are used to measure "speed", are set somewhat abstractly because there is (AFAIK) no simple linear correlation between sensor output and key position. (Btw: if someone knows these PNOscan boards, what sensors are they using? Brand? Part number?)
I was also thinking about hall sensors. They would be a little bit more resistant against dust settling below the keys. I wonder if they'd noticeably affect the mechanical resistance/inertia/behavior of the key?
What sensors/sensor setups would you recommend?
How about linear encoders? I guess the price would be prohibitive if taken times 88?
Are there ready-made sensors that use a movable part with variable translucency? I think the AvantGrand is using something akin to that as a second, additional sensor row below the keys to transmit key positions continuously.
Other ideas?
The minimum time delta to measure speed/velocity is around 0.3ms. Let's assume 0.1ms to be on the safe side. That should result in 127 MIDI velocities (at least, MIDI 2.0 supports more), and the sensor setup should be able to reliably produce those velocities with a variation no more than +/-1. Next question would probably be: is this a linear transformation? ie. 0.1ms -> 127, 0.2ms -> 126, etc.? If taken verbally, it should imply taking the inverse because of how speed is defined: v=s/t -> t=s/v where s is a fixed length of nonphysical units. For 0.1ms and 127 we get s=v*t=12.7 "ms". For v=126 we get t=12.7 "ms"/126 = 0.1008ms. So, the most extreme case requires a resolution of sub 1 microsecond, even a bit lower if we consider that we are actually measuring two times and this is really a time delta.
What are the capabilities of the various sensors mentioned (and not mentioned)? Is a gray sensor capable of delivering such a time resolution?
Next question is: how to feed those 88 sensors into a ADC/processor to evaluate the data on-the-fly and put out the MIDI events? Using an ADC or even a global ADC is probably prohibitive considering the sub microsecond resolution requirement. The DIY solution by Cybergene has trim pots on the gray sensors to set the levels between which to measure the time delta (AFAIK). It's probably necessary to go down a similar route, though I would have preferred to feed all gray sensors into a single ADC in order to have maximum post-processing freedom in software.
All comments and thoughts welcome.
TY!
p.s. the Bechstein digital system claims a scan rate of 20 kHz. According to my own calculations they should have a hard time reliably identifying a lot of the higher velocites if they use it to identify the time delta between two fixed sensor values. Maybe they are doing it differently? Maybe they evaluate the slope of the continuous measurement points or some other sort of data aggregation? But that then makes me wonder whether they are actually measuring something that's not really corresponding to the speed at a sensible trigger/strike point but is more like a washed out/average measurement over a longer movement?
Last edited:
