Kawai K1: 100% accurate velocity curves – provided by the firmware ROM

Some users reported that the velocity response of my K1v plugin is quite different compared to the K1 hardware. And yes, that is probably the area with the biggest difference between the K1v and the K1.

As I have pointed out in an earlier article, tracking down the velocity curves is very difficult, as there is no way to get the raw velocity data. What you will capture on the audio out is always the envelope volume – modulated by the velocity curve. Getting the raw velocity data is impossible.

A different approach – using the K1m Firmware ROM

While sitting here and thinking about how to solve the unsolvable problem, I had an idea. The K1 needs to have the curves stored somewhere. I used my PHm ROM that I have dumped earlier and loaded it as raw data into my wave editor.

It didn’t took very long until I found interesting data tables that looked similar to the velocity curve graphs in the manual. Actually, there a plenty of data tables in there. Not only velocity, I also found the key scaling curves and lots of other tables. I still need to figure out what they are for, but the result will be a much better precision in the K1 emulation.

Velocity Curves (length 64) & KS Curves (length 128) in Kawai K1 firmware ROM

The velocity curves have a length of 64 bytes each and have a range of 0 to 127, as you’d expect for velocity values. I extracted them from the ROM and used them in the K1v, but unfortunately they did not really match the K1 output.

Some things that I observed:

  • Velocity Curve 1, that is supposed to be linear, is not linear. Velocity Curve 3 is linear although it should not.
  • In my recordings, for most curves, velocity values above 100 do not make any difference anymore. But the curves have proper values, why aren’t they used?

Data Analysis

Lets first have a look at what the manual says VS what is in the data:

Velocity Curves – as stated in the K1 manual
Velocity Curves – as part of the K1 firmware ROM

What can be seen immediately is that all curves in the ROM are less exponential than required.

Furthermore, not the whole velocity range is used, at least not when modulating envelope volume. Take a look at the picture below, this is a K1 recording of Velocity Curve 1 with all velocity values from 1 to 127.

Velocity Curve 1 – Velocity Levels 1-127

As you can see, envelope volume is peaking way before velocity maximum. To be precise, the maximum envelope level is reached already at velocity 102. I made the gap in the recording on purpose by inserting a quarter after velocity 100 so I had to count less bars to find the values 😊.
The same applies to all other curves. Either the incoming velocity values are fed through some other table before the curve is applied, or afterwards. By testing different values and their result, I was able to verify that there must be another remapping before the velocity curves are applied.

Implementation details

It took me many hours, a lot of guessing, thinking & testing before I found the correct table in the firmware ROM. It turned out that it is a table with a length of 64, it looks like this:

Velocity remapping before being fed into the different velocity curve tables

This curve explains why very high velocity values do not make any difference anymore, they are cut off. Furthermore, the whole curve makes everything a little bit more exponential.

I was pleased with the result: I had steps in envelope volume values at the same velocity values than my K1m. The but came quickly as the values didn’t match the K1m.

K1m Velocity Curve 7
Intermediate result of K1v Velocity Curve 7

To make the result more exponential, I had to search for a table with a specific size: The envelope level has a range of 0 to 100, so a table with 101 values had to be the correct one.

As I had worked on this topic for such a long time, my source code with all kinds of tables grew more and more 😁 And now definitely needs some cleanup.

Firmware ROM tables converted to source code

Luckily, I found the correct table within one hour or so. It is a 16 bit table, it has a length of 101 as expected and makes the curves identical to the K1m.

Once more, Velocity Curve 7 as being output by the K1v, now 100% accurate:

Final result, K1v Velocity Curve 7 – identical to hardware K1m

You might see that there are very small differences due to rounding errors, but these shouldn’t really matter.

Two more pictures, a comparison of all velocity curves in all its glory 👍

K1m hardware Velocity Curves 1-8
K1v emulation Velocity Curves 1-8

Pending work

As I have confidence about what tables make up correct velocity curves, I need to implement proper modulation levels. So far, everything you see is at Vel => Env Mod +50, i.e. 100%. Special care needs to be taken when implementing the modulation strength as I currently have the impression that a value of +25 does not mean a modulation strength of 50%, there might be another remapping table being inserted to do this. Negative strengths are another topic that might be interesting.

Of course, once I’m done there will be another post to announce the release of the update.

Other useful data tables in the firmware ROM?

There are some other tables in the ROM, both 8 bit and 16 bit with data that looks interesting. If I can figure out what they are used for, I can improve the emulation a lot.

A 16 bit curve, length 101. Values from 1536 to 0 (at center) to 1536. Most probably modulation depth remapping
Another 16 bit curve with length 101, value range 0 – 4000. Most probably vibrato depth + others

For the latter curve, it looks very similar to one of my own curves that I had figured out by analyzing wave data.

Conclusion

If I ever go to emulate another synthesizer, putting more effort into ROM analysis instead of recording hours of data is the better way to go 😊 Stay tuned & thanks for reading!

Kawai K1: I dumped the K1m Wave ROM!

I was not 100% happy with my waveform recordings, I outlined it briefly in one of my previous articles, where I explained how I recorded them.

The recordings still had the issue of being quite large in size, and more importantly, they contained noise. It’s not just simple noise from some amplifiers (that one is also there, but very low). The K1 resamples the waveforms pretty badly and the aliasing that this produces is clearly audible.

Don’t get me wrong, of course, I want to recreate the aliasing and the dirtyness, as it is part of the K1s character, but it does not help if it is already part of the waveforms, which should be as pure as possible as they are pitched during playback. The aliasing needs to be added at a later stage in the audio generation process. Details about it can be found here.

Furthermore, working with recordings from a device introduces a lot of errors in general: The data has to go through The K1s D/A converters & amplifiers, the cables that go from the K1 to the recording interface and the A/D converters of recording interface itself all introduce small unwanted modifications to the signal

K1 Wave ROM Chip Data

I was browsing the K1 service manual, my intention was to repair my broken K1m, which still suffers from broken envelope attacks, when I noticed the pinout of a chip that had the letters WAVE ROM behind it.

K1 Wave ROM pinout, taken from the service manual

If you have read some of my other articles, you might know that I’m a bit into Home Automation things. For this, I not only buy ready-to-use devices, but also create my own, using Arduinos or similar microcomputers. Given that the pinout of this chip is pretty straightforward, just some address lines and some data lines, I wanted to give it a try.

The service manual lists the used chip as being a HN62304BP. I’ve searched the internet and found a data sheet. I verified that the pinout was identical to the Kawai layout.

HN62304BP data sheet

More information that I’ve taken from it: Its size is 4Mbit, or 512KiB and the operating voltage is 5V.

5 Volts perfectly fits an Arduino, but having 19 address lines and 8 data lines, my Arduinos and NodeMCU devices that I have laying around lack plenty of GPIOs for this job. Therefore, I ordered an Arduino Mega 2560 R3 which has a lot of them, 54 digital GPIOs in total.

Preparing the Arduino Mega

I wrote the Arduino code upfront before my order arrived. I used a Google Spreadsheet to help deciding which pins of the Arduino I use to keep the wiring chaos at a minimum. Then, I created some mapping tables in the Arduino Code.

Google Spreadsheet
// ROM Pin Name                           D0 D1 D2 D3 D4 D5 D6 D7
// ROM Pin Number                         13 14 15 17 18 19 20 21
const int romDataOutputs[dataBitCount] = {4, 5, 6, 7, 8, 9, 10,11};

// ROM Pin Name                          A0  A1  A2  A3  A4  A5  A6  A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17 A18
// ROM Pin Number                        12  11  10  9   8   7   6   5  27 26 23  25  4   28  29  3   2   30  31
const int romAddrInputs[addrBitCount] = {42, 40, 38, 36, 34, 32, 30, 28,31,33,39, 35, 26, 29, 27, 24, 22, 25, 23};

After it arrived, I wired a breadboard to the prototyping shield that came with the Arduino according to the specifications of the ROM chip. After having everything wired up, I was quite happy that it didn’t look too chaotic, definitely maintainable.

A prototyping shield sitting on a Arduino Mega 2560 R3, connected to a breadboard, ready to hold the K1 Wave ROM chip

I did a dry run to verify that the code works fine, fixed some issues here and there and then started to desolder the K1m Wave ROM.

Desoldering the Wave ROM

Given that the chip is not socketed , I had some work to do 🤔 I didn’t want to risk ruining the K1 at all costs so I had to be extra careful! The plan was to put the chip back into place after having finished reading it.

I started by adding fresh solder to the pins and furthermore connected each pair of two pins together. This was a preparation for the next step, I heated the new joints up again and used a pump to remove it. The result was pretty good already, some pins required some manual extra work but after a while I was able to remove the chip.

A work-in-progress image
Here we go, the K1m wave rom chip
K1m Wave ROM chip on a breadboard

First look & listen at the ROM data

19:26:51.169 -> Dumping ROM data
19:26:51.169 -> 524288 total bytes
19:26:51.169 -> 0000000 00828384178491050b099b0a0c870a899d1a21b217039a1908a0071591931f96020e90891103920683861a09ad2613da320d981605c11240a142ba025e9ab430 ..................!..........................&..2......@.B..^..0
19:26:51.203 -> 0000040 160499b0a71a1f1bc99758a8a0b7903d308683008a31aea7222e8abb961e60a3010e82969db58c54a3050b9e2290ad149b851801860690270f9829b32407c881 ..........X....=0....1..".....`........T...."..........'..).$...
19:26:51.237 -> 0000080 800b3b0cae2224a3199b88052ca20f9b88499304a1aa3727bb851a033fba8b46b40b34c4904b9600b79060a1c92c9a4a98b0060b2b09959f11b39e8f06008c03 ..;.."$.....,....I....7'....?..F..4..K....`..,.J....+...........
19:26:51.271 -> 00000c0 839ba41225971d1a020d9ca54c8d911cad101ab20e3a1b348aa817a99918b834119d08a8820e9d00071092871f1319a2112101b99eb8411e98200c082d89af0f ....%.......L........:.4.......4.................!....A.. ..-...
.........

After the dump had finished, I had a first look at it, mainly to verify that my code to dump the ROM was not faulty, I didn’t swap any address lines and such.

I have not been able to find any text or something that would tell me if the dump was correct or not. I verified that all 8 bits are not always zero and not always one, but I couldn’t guess if the data is correct just by looking at it in a hex editor. As it is a Wave ROM, assuming it might contain mostly audio data, I converted the text dump into a binary and loaded it in a wave editor.

When I saw and heared it I was so excited! 😍 Although something was obviously wrong, at the same time, it verified two important of things:

  • I didn’t swap any address lines or data lines
  • The ROM had no encryption that I would’ve had to fight against
Wave ROM loaded as PCM data

Though I recognized some of the used waveforms, they appeared to be heavily distorted. I imported them both as signed PCM and unsigned PCM data, but that didn’t help.

I browsed a bit in the ROM and found the sine single cycle waveform.

Broken Sine wave form

Apparently all negative waveform values were inverted. I added a small code snipped to the wave ROM text-to-binary converter to fix it:

// convert audio data to signed PCM data
for (size_t i = 0; i < data.size(); ++i)
{
	unsigned int d = data[i];
	if (d >= 0x80)
		d = 127 - d;
	data[i] = d & 0xff;
}

After I did that and loaded the wave ROM again I got goosebumps! 👍All waveforms were present, in a quality that is, obviously, much better than anything I had before.

K1m Wave ROM

Wave ROM data analysis

Having the data as audio data, I was able to verify that there is only audio data in it, there is no meta information, such as offsets, any kind of init pattern, whatever. The whole ROM consists of audio data only.

PCM data

I began analyzing the file by adding markers to the waveforms. What I got quite quickly is, that every waveform has a length that is a power of two. The lengths are different, ranging from 4096 samples (some of the drums) to 32768 samples (choir, strings etc).

Knowing that every length is a power of two helped a lot to set the markers at their correct positions, resulting in perfect loop points.

What I also noticed: There are only 30 PCM waveforms in it, although there are 52 PCM waveforms that you can select. This is because the waveforms are used multiple times. For example, there is a one-shot Voice (Wave 233) and a Voice Loop (Wave 238). They are based on the same waveform. This is the same for all loops.

The reversed waveforms that you can select are not present, the K1 generates them in realtime by just playing the waveform backwards.

All „Alt“ loops are not present either. The K1 plays them as forward-backward-forward-… loops.

All „Omnibus“ loops just play through a larger range of the wave ROM. If you listen to the audio above, you can even hear all of them. For example, Omnibus Loop 8 plays a loop consisting of 6 waveforms: F. Guitar, A. Guitar, Piano Noise, Pan Flute Attack, String Attack and Bowed String. Its easy for the K1 because that is the layout in the Wave ROM. The picture below illustrates it.

Omnibus Loop 8 in the Wave ROM

On the left side of the picture, you can see how I named my markers. I use these markers to map segments of the Wave ROM to waveforms 1-256 when I load the Wave ROM in the VSTi plugin.

Single Cycle Waves

The single cycle waves are stored in the Wave ROM, too, but in a much different way.

Single Cycle Waveforms in the Wave ROM

It took me a while to understand what I am looking at. Initially, I thought that my conversion code is broken and that there is still a signed/unsigned/something mismatch.

One of these cycles is always 128 samples long, something that I’ve read previously somewhere. And each cycle seems to exist 5 times. Why? And these snippets are definitely not loopable.

What helped me to understand this is to compare the wave ROM data against my recordings:

Recording of wave 14 (First Saw)
Wave ROM data of wave 14 (First Saw)

What the K1 does is, it uses the cycle twice. To form a loop of one waveform, it uses it once in forward mode, the second part is the same cycle, but inverted and negated. If I do this manually in the wave editor, the result looks like this and is a perfect match to the recording:

So what is stored in the ROM are half-cycles only.

The next topic was to figure out why there are always 5 repeats for each waveform. I quickly verified that this is always the case for all single cycle waveforms by calculating the following:

  • The total data length for all single cycle waveforms in the Wave ROM is 130560 samples
  • Divided by 5 (number of repeats), the result is 26112
  • Divided by 128 (length of one cycle), the result is 204. This is the value that we expect as the K1 contains 204 single cycle waveforms

In one of my previous articles, I talked about that some of the single cycle waves are multisamples, and this is what the 5 variations of each waveform are for.

Now the only problem was to find out when to use which multisample. I had another look at my multisample markers that I’ve put into my recordings and noticed that, if there is a multisample transition, they always happen at the same notes. Something that I just didn’t notice. After looking at each of my recordings and writing down the notes, I had a list of 5 different notes that were used, exactly what I was looking for. The final mapping for multisamples is:

MultisampleMidi Note Number Range
10-47
248 – 59
360 – 71
472 – 83
584 – 127

You may have noticed that the range of one multisample is one octave and that there is support for 5 octaves in total. The reason why I didn’t recognize all multisamples while recording is, that not every waveform uses them. For many waveforms, the data in each multisample is identical.

Conclusion

After adding support to load the Wave ROM in my emulation, the quality increased significantly! 😎
Some of the not-really-good sounding singles now perfectly match the real K1. Especially bell-type sounds that use the amplitude modulation were missing the very low and very high frequencies, now they are as present as on a real K1. I’m going to post new audio demos soon so you can hear the improvements.

One final step is missing: I still have to put the Wave ROM chip back into my K1m. Instead of adding it directly, I’m going to add a socket to the K1m board and insert the Wave ROM there. The socket didn’t arrive yet so I have to wait some days before doing so.

Update: The socket has arrived and the K1 is fine again.