Piano World Home Page Forums Our Most Popular Forums Digital Pianos - Electronic Pianos - Synths & Keyboards [BUG][Kawai CN37(/39/CA59/ES8/ES920 too?)] Key-Transpose

The feature is that the virtual technician operates on the note normally associated with a given key. If you apply the VT to the C8 key, it sppkies tge change to the C8 note. If you do a +1 transpose, the B7 key generates the C8 note with the VT change.

Those are legitimate requirements for the feature. It is different from how you wish it to work. If that was the requirement for the feature, then it was implemented correctly, and is not a bug. If the requirement was that it should work they way you have described you would like it to work, then it is a bug.

Typos corrected.

The feature is that the virtual technician operates on the note normally associated with a given key. If you apply the VT to the C8 key, it applies the change to the C8 note. If you do a +1 transpose, the B7 key generates the C8 note with the VT change.

Those are legitimate requirements for the feature. It is different from how you wish it to work. If that was the requirement for the feature, then it was implemented correctly, and is not a bug. If the requirement was that it should work they way you have described you would like it to work, then it is a bug.

I passed on your comments/findings to some colleagues in R&D.

The steps required to reproduce this behaviour (and the reasons for doing so) are somewhat convoluted, and therefore unlikely to affect a significant number of customers.

As a result, I would not get my hopes up that the reported behavior will be changed...but hey, well done for finding it, I guess?

Kind regards,
James
x

I don’t know of any piano that allows tuning outside of 88 keys so I imagine that they have the same issue.

Your use case is so far outside the norm that I can’t imagine there will be a change.

I guess it would be interesting to know if the volume adjustment stays with the key or note.

Sweelinck, I think the actual bug is not that the per-key tuning doesn't consider the key-transpose (this indeed could be by design)... The bug is that when you use key-transpose function, the per-key tuning doesn't allow to tune the "new" notes that the transpose generates. For example, if you do a key-transpose of "+2", you'll lose the first 2 notes (A0 and A0#) but you'll get 2 new notes at the end of the keyboard: C8# and D8. The bug is that you'll not able to do a fine-tuning of these 2 new notes... In the same way, just as an extreme example, if you do a key-transpose of "+12" you'll not able to fine-tune the newly generated 12 notes at the end of the keyboard (C8# -> C9), but just the 76 notes from A1 -> C8! Do you think this is a feature? To me this is a bug.

Now, as a software developer, how I would fix the issue without displeasing anyone and with minimum work? In this way:

- Considering that when you use a key-transpose of "+n" you'll lose the first n notes in the range A0-C8, but you'll gain n new notes at the end of the keyboard, you could just re-use the first n unused slots to set the tuning of the newly generated notes.

For example, now when you do a key-transpose of +4, in the range A0-C8 of the per-key settings:



there will be 4 unused informations for the first 4 notes (because with a +4 as key-transpose they will get out of the usable range). At the same time we'll not be able to tune the new 4 generated notes, C8# D8 D8# E8, because we have no specific slots for them in the A0-C8 range of editable per-key settings... BUT! If we used the first 4 unused slots to set the values for the newly generated 4 notes we could get the desired result without changing the actual User Interface and we would preserve the requirement of who prefer the actual behavior too!

P.S.: this would work in the other way around for a negative transpose too... In this case the unused slots will be at the end so we could use them for the tuning of the newly generated first n notes.

Thanks James, maybe my suggestions in my previous post could be used for future DPs. And personally I would make an option to let the user change the timbre of any piano patch by automating the steps I described at the end of this post: LINK. This would give the user many more piano variations for each piano patch.

An option like: "Piano timbre: from -4 (more clean/brilliant) to +4 (more colorful/detailed)"...

Yes, I checked and the issue is with "all" the per-key settings. The basic principle is the same: actually the per-key settings act "before" the key-transposition, so they will always change just the original pitches and the user will not be able to change the per-key settings of the "n" new notes generated by a key-transposition of "+/- n".

The issue is you are trying to get a new tone out of the piano by hacking the tuning.

The simpler solution is for Kawai to offer more tone adjustments and not mess with the tuning when it is transposed.

The way it is working now is correct, tuning stays with the note and you don’t want to have to retune notes every time you adjust the transposition.

I do think mac3 did make a good point and volume adjustment might need to stay with the key.

As a software developer, I'm sure you understand that the correctness of software is measured by its conformance with a requirements spec, and not whether the requirements are what you prefer them to be.

I would not prefer the behavior you prefer. If a bunch of changes are made while transpose is set, and then it is turned off, I have to remember what transpose was in effect to undo the changes easily. What is needed is for the VT changes to be associated with the transpised state, and not global changes. This will be a more involved implementation. If there will just be one set of VT settings for one transpose state, transpose 0 is the correct one. Do all of your VT work with transpose set to 0.

I get that it means you cannot use VT to modify tones beyond the 88 notes of a piano, but those notes are out of the musical range of the instrument. They are not piano notes. The purpose of the transpose is that if you, say know how to play something in the key of Am, and want to play it in, say Cm, you can just use the transpose and play the keys for the Am rendition. This is used when accompanying a singer or playing in an ensemble where others want to sing or play in a different key. In this usage, the music still uses (a subset of) the 88 notes of a piano.

I think that people who actually sell the product are more interested in what their customers prefer. Customers pay the bills. Specs do not.

Mmmh... Do you work as a Kawai's lawyer?
Yes, I'm a software developer but in this case I'm a customer, so, sorry if I'm more interested in "my" requirements, more than the requirements of the manufacturer... And to be honest, I don't know the designer's specs (I don't think they are public!), so I can only speak for "my" requirements, as a customer.
No, you don't have to remember the changes to undo them, because if you change something, a power-off and power-on of the instrument will reset the settings. And if you want to preserve your settings after a power-off, usually you use a "Registration Slot" that is meant just for this: to save your custom settings without altering the default behavior. I do this all the times on my CN37, so that the default settings are always preserved, even after some "heavy" editing of the settings.

Anyway, my suggestion to fix the issue was just a "suggestion". I know they'll never care to fix it. And I understand that you don't care for this issue or that you don't consider it an issue at all. But in my use case it's an issue. Different people, different needs...

@magicpiano

Again, what you really want is another tone for the piano. I believe you will have more success asking Kawai for that.

Listing this as a bug is likely not correct. I believe all manufacturers that offer individual note tuning have dealt with this issue the same way.

Sure, but lack of compliance with your requirements is not the definition of a bug.

@Purdy:
I just want to use all the means made available by the piano engine (and my imagination) to get as much as possible from my DP. What's wrong with that? In doing this, I encountered a software issue (or software limitation, call it what you like). I reported the issue. I know (at 99%) the issue will never be fixed in current DPs, but maybe in the future some kind designer could consider to accomodate my request in future DPs, who knows?

P.S.: it would be interesting to know what happens with a similar function in DPs from other brands, but anyway to me this issue is a "design" bug, meaning that the designer didn't foresee the ability to use key-tranpose + per-key settings, so the newly generated notes from the key-transpose actually are not customizable.

True. And the people that design the product take (usually) what customers want and create specifications, which are the base for all product development forwards. When properly done, the specifications meet most needs of most customers of a given product. Of course, specs may change along development, within the reasonable, trying to balance quality, cost, lead time, but too flexible specs lead to costly, delayed or no product delivered. It one tries to please everybody, they may end like these:

It's not the designers who do that. Nor the software developers.
Marketing initiates all of that.

It’s an interesting problem but when you transpose you’ve created a note(s) that doesn’t exist on a 88 key piano and thus is not played.

Your looking for a solution to a problem that doesn’t exist.

Even transposing itself is likely a not often used feature in these more expensive digital pianos.

If you are looking for more control of the sound engine, I think that is very reasonable, and the better vst pianos have options that you don’t have built into digital pianos.

Again i would say putting efforts into adding more control would be a better use of resources than supporting a very fringe case that might only be used by one person.

If a company implemented your proposed solution would you sell your existing piano and buy it?

But it is an interesting issue and thanks for bringing it up.

Agreed. You obviously get the idea.

Yes. But the requirements were developed in the past. If additional or different customer preferences become known, those can be incorporated into requirements for future versions or products. We don't kbow what the requirements were.

I would not pay a penny more for a DP to have it do what magicpiano wants. If the purpose of key transposition was to simulate hypothetical pianos with a different range of notes, then this frature would be a logical thing to implement. But I believe the use case key transposition was included to suoport is to accompany in different keys, so that there is no need to support keys outside the 88-key range.

You don't know that it was not foreseen. It may be a design bug. It may be that there were intentional reasons for leaving the feature out (not worth the cost of implementing it, not a relevant feature, save memory space for code storage, ...)