|
Welcome to the Piano World Piano Forums Over 3 million posts about pianos, digital pianos, and all types of keyboard instruments. Over 100,000 members from around the world.
Join the World's Largest Community of Piano Lovers
(it's free)
It's Fun to Play the Piano ... Please Pass It On!
|
|
67 members (BillS728, Burkhard, aphexdisklavier, bobrunyan, anotherscott, AaronSF, apianostudent, 19 invisible),
2,249
guests, and
373
robots. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Joined: Sep 2009
Posts: 14,439
Yikes! 10000 Post Club Member
|
Yikes! 10000 Post Club Member
Joined: Sep 2009
Posts: 14,439 |
I don't think this is related to MIDI. It's about measuring the hammer velocity.
|
|
|
|
Joined: Jun 2020
Posts: 646
500 Post Club Member
|
500 Post Club Member
Joined: Jun 2020
Posts: 646 |
And I am also speaking about hammer speed. If the end result of the controller is to transmit the hammer velocity in a linear range of 0 to 127, it is irrelevant to substitute a hardware solution that is able to separate 52.3 from 52.4 (in both cases the transmited value will be 52) to a fancier but more complex hardware solution that separates 52.323 from 52.324 (it will also output 52). CG solution surpasses the MIDI resolution, hence there is no fundamental need to make a radical change in strategy. This does not mean that there is no merit... I mean that there is no need for one PIC per key or per octave.
Teensy is a PIC...
Last edited by vagfilm; 10/23/20 12:29 PM.
|
|
|
|
Joined: Jun 2020
Posts: 646
500 Post Club Member
|
500 Post Club Member
Joined: Jun 2020
Posts: 646 |
I am past the time to edit my previous post. What I meant is that PIc is one type of microcontroller while teensy is based on another (more powerful) microcontroller. Substituting a solution that uses 1 microcontroller with one that requires 88 microcontrollers is a bit overkill.
|
|
|
|
Joined: Sep 2009
Posts: 14,439
Yikes! 10000 Post Club Member
|
Yikes! 10000 Post Club Member
Joined: Sep 2009
Posts: 14,439 |
You know ... controllers are funny. When we were designing the first flip phones 25 years ago we decided to put a dedicated controller in the top (display) portion of the flip, separate from the controller in the bottom (keypad) portion.
If we had just put one controller in the handset portion, then the matrix wiring for the display would have to be run from the bottom half to the top half. And a flex to carry a hundred or more conductors .. would have been more expensive and less reliable. It seemed absurd ... but a controller can be cheaper than wire. Crazy.
Controllers were getting pretty cheap then. I wonder ... how much does a pic or teensy cost today?
|
|
|
|
Joined: Oct 2020
Posts: 53
Full Member
|
Full Member
Joined: Oct 2020
Posts: 53 |
We must not forget the intrinsic limitations of MIDI (Note-on, note-off transmission of values in the range 0-127, at very low speed). That's all. There is no need to full nanosecond resolution of key or hammer instantaneous position. Since I've seen some posts on MIDI 2.0 and velocity resolution etc etc, and I'm getting myself involved in something tangential, I'll lay out right now that my opinion is that a keyboard should be designed to generate about 8-10 bits of velocity, on the theory that the bottom 1 or 2 bits of any analog to digital conversion process are pure fantasy. The simple method of sequential reading of keys looks very non-sophisticated, but it is still faster than the rate of MIDI transmission, so there is no need to be even faster. In an ideal world I think MIDI keyboards ought to be able to generate note on messages slightly sooner than an acoustic would start making noise, so that the rest of the synthesis chain has plenty of latency budget left to work with. It is much easier to tell the keyboard to add a few milliseconds of delay back in than to try and get one's PC to generate the notes sooner. Measuring at the key stick or anywhere else before the hammer impact probably ensures this, but "faster than MIDI [signalling]" is not quite sufficient, IMO. - include a 4th reading per key to allow for key-off speed; this would require 4 trimpots per key instead of 3; - in alternative to the above, making the voltage thresholds software based instead of hardware based: this would permit to increase or decrease the number of readings per sensor without changing PCBs. I really don't know if this is possible at all; more expert people (Jay?) can comment on this. This is part of what the ADC-based approach is intended to accomplish. By digitizing the sensor value and processing it in software on a microcontroller, we can have 4 readings, or an arbitrary number of readings processed in fancy ways (if we want; the Cybrid demonstrates it probably isn't necessary). The thresholds also become software adjustable. The use of comparators is very effective, but to stick with them while getting software control of the set points, you'd have to use DACs to produce the comparison voltages. Having 3 (or 4!) passably high-resolution DACs per sensor plus corresponding comparators is more expensive, more parts and less flexible than just feeding in to a microcontroller with an ADC. Going to that fourth comparator also represents a 33% increase in the number of digital signals you've got to monitor. So you're up to 352 (88*4) signals you want to monitor. It can be done, but you'd need to overhaul the "note bus" of the Cybrid to accomodate it. If someone wanted to pursue that I can outline how I'd do it. The other part of what the ADC-per-sensor is intended to accomplish is the ability to capture hundreds or thousands of measurements from the sensor as a key is pressed, during calibration. I'm hoping that with that information all of the thresholds can be chosen by a piece of calibration software, rather than being tweaked by handed.
|
|
|
|
Joined: Oct 2020
Posts: 53
Full Member
|
Full Member
Joined: Oct 2020
Posts: 53 |
I mean that there is no need for one PIC per key or per octave. "Need" doesn't really come in to this. It's about engineering trade offs. Putting a microcontroller on every sensor not only satisfies the requirements, but provides additional functionality, at a lower cost. I appreciate that it doesn't feel parsimonious, and seems silly, but sometimes that's how these things go. I'm unwilling to burn my time on Aliexpress trimpots, so my cheapest reliable source is something like $1.7/per. That's $5.10 in trimpots per key. The dsPIC I'm considering is $2.89. It is also surface mount, so if someone wanted to have this professionally assembled, it should be cheaper to have a single SMT part put onto a board than 3 through-hole trimpots. There's also NRE to consider: There's no amount of money I can be paid to sit and turn 264 pots. CyberGene's patience boggles my mind. But I'll fiddle with software to automate that all day long. It seemed absurd ... but a controller can be cheaper than wire. Crazy.
Controllers were getting pretty cheap then. I wonder ... how much does a pic or teensy cost today? Indeed, modern microcontrollers violate a lot of expectations, they've just got so much stuff crammed into them, and they're produced in such insane quantities that the cost is driven below expectations.
|
|
|
|
Joined: Sep 2009
Posts: 14,439
Yikes! 10000 Post Club Member
|
Yikes! 10000 Post Club Member
Joined: Sep 2009
Posts: 14,439 |
You need to rethink this ... I'll lay out right now that my opinion is that a keyboard should be designed to generate about 8-10 bits of velocity, on the theory that the bottom 1 or 2 bits of any analog to digital conversion process are pure fantasy. An A/D conversion can be as accurate as you're willing to spend. In this application the limits of precision lie almost entirely in the mechanical portions of the piano action. Also, the limits of hearing preclude the need for more bits of velocity. CG and I have both railed on that point.
|
|
|
|
Joined: Oct 2020
Posts: 53
Full Member
|
Full Member
Joined: Oct 2020
Posts: 53 |
You need to rethink this ... I'll lay out right now that my opinion is that a keyboard should be designed to generate about 8-10 bits of velocity, on the theory that the bottom 1 or 2 bits of any analog to digital conversion process are pure fantasy. An A/D conversion can be as accurate as you're willing to spend. Yes, you can always get more bits by spending more money. I see the budget as being a couple dollars per key, which leaves us in the realm of 12 bit ADCs that are going to have errors of +/-1LSB on a good day. And the ADC resolution is unlikely to directly translate into velocity resolution. If it is used purely to implement "software comparators" or fixed thresholds, then it'll be the timers that determine the velocity resolution. If the ADC values feed in directly, I expect some nonlinearities. Also, the limits of hearing preclude the need for more bits of velocity. CG and I have both railed on that point. I see myself disagreeing with you two by at most a bit or two. I just think the hardware should plan to collect a couple more bits than is necessary, to push the electrical/conversion noise solidly into the part that we both agree doesn't matter.
|
|
|
|
Joined: Sep 2009
Posts: 14,439
Yikes! 10000 Post Club Member
|
Yikes! 10000 Post Club Member
Joined: Sep 2009
Posts: 14,439 |
It depends on how much velocity resolution is enough. I've said time and again that 7 bits is more than enough. The hands cannot take advantage of more, and the ears cannot detect more.
|
|
|
|
Joined: Apr 2007
Posts: 7,268
7000 Post Club Member
|
OP
7000 Post Club Member
Joined: Apr 2007
Posts: 7,268 |
(On the phone, so can’t write long)
I’m a big proponent of the PIC solution and as I said I was considering it since the beginning but my lack of experience stopped me. I like it exactly for two reasons:
- You can define as many measurements points as you want and thus measure also release velocity. - You can automate calibration to a high degree, for instance just play all the keys and you will have hammer max position (strike point). For the others you may just use a spacer. No need to turn trimpots.
However I never imagined a PIC per sensor. Rather per group because I believe the speed will be good enough (or is that really so?). Or basically it will be a map-reduce solution compared to my current one, namely scan through 5 notes and determine their velocities, then the main controller will scan through groups and just gather their data (ready velocity). Or use a bus protocol: SPI, I2C, CAN etc.
Last edited by CyberGene; 10/23/20 02:19 PM.
|
|
|
|
Joined: Jun 2020
Posts: 646
500 Post Club Member
|
500 Post Club Member
Joined: Jun 2020
Posts: 646 |
I am the last person to tell someone not to pursue a fun project. Go for it, Jay... You probably don't even need a lot of mcus since pics have a lot of ADC channels and only one channel is needed per optical sensor. With anything from 5 to 8 PICs (depending on the chosen PIC) you cover the 88 keys. Using a fixed and low sample rate you can calculate instantaneous speed and hammer position per channel (or take the yamaha way and read key position). But you still need to have a master clock to sync all PICs...
Last edited by vagfilm; 10/23/20 02:18 PM.
|
|
|
|
Joined: Oct 2020
Posts: 53
Full Member
|
Full Member
Joined: Oct 2020
Posts: 53 |
It depends on how much velocity resolution is enough. I've said time and again that 7 bits is more than enough. The hands cannot take advantage of more, and the ears cannot detect more. I think we're in agreement, then, or near enough. You probably don't even need a lot of mcus since pics have a lot of ADC channels and only one channel is needed per optical sensor. With anything from 5 to 8 PICs (depending on the chosen PIC) you cover the 88 keys. Using a fixed and low sample rate you can calculate instantaneous speed and hammer position per channel (or take the yamaha way and read key position). It may be possible to reduce the count, yes. I'll know a lot more when I've got one of these PICs taking readings off a sensor. On some level I suppose "processor per key" is like a worst case scenario? Even if I've got to use 88 of them, it remains cost effective and technically feasible to get them all to communicate. Life is certainly easier if I need fewer of them, both in that there will be less soldering the prototypes, but also it would dramatically increase how much could be spent on the individual controllers. (ADDED) The controller-per-key also came about at a point where I was thinking of putting the controller on the same little board as the optical sensor, for signal integrity. But I've moved away from thinking, for wiring reasons. It's maybe less useful than I'd originally thought, but, like I say above, it's nice to know that even if I do need that many, it should still be cost effective. But you still need to have a master clock to sync all PICs... I was expecting I'd need to send a pulse per second onto the CAN bus from the master controller, to account for any drift/variation in the internal oscillators. Or go backwards and have the individual controllers broadcast once a second according to their clocks, and let the master controller watch that and account for it. More bus traffic, but less work for the (slower/dumber) dsPICs.
Last edited by JayKominek; 10/23/20 03:38 PM.
|
|
|
|
Joined: Jun 2020
Posts: 646
500 Post Club Member
|
500 Post Club Member
Joined: Jun 2020
Posts: 646 |
Regarding sync I believe it depends on the strategy chosen for inter-mcu communication: CG suggested a master mcu (teensy for example) doing sequential reading of each slave mcu and in that case there are no sync problems (my naive and non-expert expectation)... On the other end if each mcu actively sends packets of data upwards, I expect a lot of sync processing.
|
|
|
|
Joined: May 2020
Posts: 682
500 Post Club Member
|
500 Post Club Member
Joined: May 2020
Posts: 682 |
they will not wait for you to spend 2-3 hours unwinding the strings Just to make nobody reading this casually misinterpret this. Unwinding the piano strings is tricky business. DO NOT ATTEMPT DOING THAT if you do not know what you are doing and how you are doing. It is not just matter of turning the pins (or worse, cutting the strings). Hence why you need the time I quoted, trying to do tricks to go faster will almost certainly result in personal injury. PS: you guys either don't post or post too much too fast!!!
|
|
|
|
Joined: Jan 2016
Posts: 3,375
3000 Post Club Member
|
3000 Post Club Member
Joined: Jan 2016
Posts: 3,375 |
There was no speed limitation on the MIDI 1.0 spec. That is dependent on transport but the 5-pin DIN cable was limited to 31,250bps.
A MIDI Association engineer wrote that he never saw (or heard about) any equipment running any faster (even over USB); he also noted that he had not made an exhaustive study.
Also, I think it is possible that music software downstream on the computer could throttle MIDI messages to 31Kbaud to ensure compatibility so that is probably worth exploring before attempting blazing data speeds at the controller.
https://web.archive.org/web/20190906211008/https://www.synthtopia.com/content/2019/01/18/midi-2-0-promises-auto-configuration-extended-resolution-tighter-timing-backward-compatibility/
|
|
|
|
Joined: Jan 2020
Posts: 26
Full Member
|
Full Member
Joined: Jan 2020
Posts: 26 |
How about 3 PICs per key?
No, really...
For around $0.50 you can get a little 8 pin PIC12F1572.
It has:
• a comparator input that can compare an analog input to a voltage generated by an internal 5 bit DAC • a comparator output i.e. the digital output from the comparator at the above mentioned input • a UART so you can send it a message telling it what threshold to detect (i.e. what 5 bits to send to the DAC) • some high endurance flash where it can store that threshold
So one of these could implement a software trimmable comparator for less cost than the trim pots on the hardware version.
|
|
|
|
Joined: Apr 2007
Posts: 7,268
7000 Post Club Member
|
OP
7000 Post Club Member
Joined: Apr 2007
Posts: 7,268 |
How about 3 PICs per key?
No, really...
For around $0.50 you can get a little 8 pin PIC12F1572.
It has:
• a comparator input that can compare an analog input to a voltage generated by an internal 5 bit DAC • a comparator output i.e. the digital output from the comparator at the above mentioned input • a UART so you can send it a message telling it what threshold to detect (i.e. what 5 bits to send to the DAC) • some high endurance flash where it can store that threshold
So one of these could implement a software trimmable comparator for less cost than the trim pots on the hardware version. Ha! That’s super cool. Indeed, it can replace the trimpots and the comparators. A particular problem would be how to multiplex the UART signals for setting the stored voltages though. P.S. Well, 5 bits means only 32 distinctive values. Not sure how good that is...
Last edited by CyberGene; 10/24/20 02:20 PM.
|
|
|
|
Joined: Jan 2020
Posts: 26
Full Member
|
Full Member
Joined: Jan 2020
Posts: 26 |
A particular problem would be how to multiplex the UART signals for setting the stored voltages though. You wouldn't need to multiplex: They could all be listening, all of the time. (And it's a one-way message so no need to get a particular PIC's reply back to base). Just program each PIC to know which key/sensor it is handling. Then send a message like: "Key 112, sensor 2, set threshold to 17" and that one PIC would know that this was its threshold being set. The 266x fanout would need to be dealt with, but no multiplexing.
|
|
|
|
Joined: Apr 2007
Posts: 7,268
7000 Post Club Member
|
OP
7000 Post Club Member
Joined: Apr 2007
Posts: 7,268 |
^ Right, that’s a good enough strategy. Only the 5-bit resolution bothers me but if you can provide an absolute offset and width of the 5-bit window, then it can be good enough.
|
|
|
|
Joined: Jan 2020
Posts: 26
Full Member
|
Full Member
Joined: Jan 2020
Posts: 26 |
P.S. Well, 5 bits means only 32 distinctive values. Not sure how good that is... I'd guess it would be good enough to get it working with a decent set of signals from each key, after which any finer tuning could be applied by adjusting the measured timing.
|
|
|
|
|
|
Piano
by Gino2 - 04/17/24 02:34 PM
|
Piano
by Gino2 - 04/17/24 02:23 PM
|
|
Forums43
Topics223,408
Posts3,349,457
Members111,637
|
Most Online15,252 Mar 21st, 2010
|
|
|
|
|
|