Inside my Yamaha piano

You can't perceive any change, because your perceptions aren't either subtle or precise. If you were an A/D converter, you'd be struggling to get beyond binary choices.

--
Bill Sloman, Sydney

It takes me to the stuff I want to see rather faster than Thunderbird. It's a vastly inferior place to generate responses, but I spend more time reading than I do posting, and I can compensate for some of the inadequancies of the posting interface.

As a posting interface. As a reading interface it isn't as good.

--
Bill Sloman, Sydney

Isn't time to come in johnny? It's getting past your bed time.

Jamie

If you hang here long enough you will find there are a number of miscreants like him here. This is a very odd collection of people who like to argue over anything but mostly nothing. They just like to argue... oh, and blame... don't forget about the blaming... oh, oh, and the insulting. No, we can't ignore the insulting either.

--

Rick

subtle or precise. If you were an A/D converter, you'd be struggling to get beyond binary choices.

There are 10 types of people in this place, those that understand binary and those that wish they did.

I believe you are one of Walter Freeman lobotomized patients, looking for their marbles.

Jamie

I found this document

which is, I think, applicable to my piano.

It looks as if the protocol is at least MIDI-like.

Sylvia.

I suppose it's possible, though I would have expected some variability in the note, rather than a consistent loud.

As far as I've been able to tell by experiment, the note doesn't sound in the absence of a start signal.

There are multiple pads, each covering a group of notes. I did swap the pads for the offending note with another, to see whether the problem moved. However, the problem is currently absent.

Sylvia.

I have no first-hand experience in that application domain. However, am basing my comments on the idea that you would have to code the implementation (even if it is implemented in dedicated hardware) to handle a variety of cases:

- START followed in a short time interval by END (nominal use)

- START followed after "too long" an interval by END (too light of a touch)

- START "never" followed by END (likely a faulty END sense)

- END never preceded by START (likely a faulty START sense)

- END followed by a START (bad/deferred START sense)

To implement this, I'd imagine a timer per key (88 keys isn't that much of a resource hog -- and, the timers can be narrow as they only need to span the interval from START to "latest tolerable END").

*Guessing* the total travel time is short enough that it can be ignored in the timeliness of the report (to the rest of the piano), you could start the timer when START is sensed and, when END is seen, read the elapsed time to determine "inverse force" (smaller numbers mean the keys are struck more forcefully -- equivalent to driving the hammers into the virtual strings harder!). So, a key-down event can be reported tagged with it's "forcefullness". (then, wait for the END and START senses to be removed)

The second case (above) could possibly result in "no key event". If you consider the real piano analog, this would be equivalent to pressing the key SO gently that it never gets enough momentum for the hammer to be THROWN into the strings (because the hammer, at full key-down, does not touch the strings!)

The third case could similarly be handled (i.e., pianist only depressed the key part way)

The fourth case requires an implementation decision: clearly, "can't happen" HAS happened. Do you treat this as a no key case? Or, do you assume a key *was* depressed (after all, END means the key is fully down!) and make a guess as to how quickly it got there? In this case, what makes the most sense: light touch, nominal touch or heavy touch?

If the implementation clears the per key timers when the key is UP (i.e., while START is false), then when END came along, the timer would still have had its initial value -- corresponding to "nearly instantaneous transition" (i.e., a HARD strike).

The fifth case would rely on how you implemented the fourth, etc.

My *opinion* would be that a piano that played a note too forcefully would be more usable than one that didn't play it at all! I.e., you could compensate and still use the piano (striking ALL keys with maximum force, if necessary to keep the bad key from standing out -- and lowering the volume to make these strikes seem less harsh).

OK. And, I'd guess the absence of an END likewise results in silence (unless the code reports events some fixed time after START sense on the assumption that END will have occurred before that point)

It just looks (electrically) like two keyboards mechanically driven by the same actuators (keys).

Aside from the nagging uncertainty ("lack of closure"), that's the BEST sort of problem to have! :>

Velocity sensing is sometimes performed with two contacts. One connects slightly before the other and time delay is converted to velocity.

--
I will not see posts from astraweb, theremailer, dizum, or google 
because they host Usenet flooders.

Your beliefs do reflect your imperfect grasp of reality.

died in 1972, and very few of his patients would still be around to look for their marbles. Happily, I haven't lived anywhere where he could have got at me.

--
Bill Sloman, Sydney

This is a picture of a few of the contact areas.

How, and why, would the different track colours arise?

Sylvia.

The yellow area *appears* to be clear of conductive traces (?) I.e., the "gap" between the switch contacts. The black area is carbon-plated. (the green "traces" are just masked).

I.e., the switch is formed by the carbonized rubber pad ("pill") on the piano key coming into contact with one set of cabon-plated tracks and bridging to another set of tracks. There are three such sets for each key due to the TWO switches involved.

(repeat this for the END and START "switches" on each key)

OK, yes, I think that's right. I hadn't looked closely at the pictures - I just took them for posting - and had perceived the yellow areas as being copper (the colour rendition in the pictures is far from accurate), but what you say makes more sense.

Sylvia.

Very likely two contacts velocity detection: when the key is pressed it first closes one contact, then as the key travels the second one is closed as well. The time between first and second contact then is inversely proportional to the speed the key was hit.

Just speculating here, maybe If the first key is broken or covered by dirt the firmware thinks it was hit so fast that the time between the two contacts is null, so it emits the note at full velocity.

Does the keyboard have also poliphonic aftertouch? It could explain why one of the keys is sensitive to pressure.

What model is the Piano?

This method of key-strike detection is typical of the FATAR company that makes the key bed. Not sure if Yamaha use them or if they designed theirs in-house or sourced elsewhere.

All my Kurzweil keyboards use FATAR key beds and after 20 or so years begin to suffer from similar symptoms (very common forum subject).

At least they moved on from the original Kurzweil K250 method:

These actually required *maintenance* - contact burnishing, leaf adjustment by bending etc..

--
Cheers 
Chris.

It's a CLP-970, but its original keyboard was replaced under warranty because of a problem with sticking keys (a widespread problem at the time), and the replacement had a different feel, so it wasn't the same design.

BTW, I wish these things had more dynamic range. There, krw will be happy - I've finally griped about this.

Sylvia.

Syntaur

has parts for your model.

I can vouch for them having bought for the aforementioned Kurzweil models.

--
Cheers, 
Chris

WHAT is that godDAMN dancing AD doing? I absolutely *HATE* this "overlay" crap that interferes with what one would like to look at, and worse that cannot be prevented.

I use AdBlocker in Chrome so I don't see any ads. I also don't see the image until I click the zoom/magnifier button. I signed up for the account in the years when it was a simple sharing site... ah well.

--
Cheers, 
Chris