Evan Sirchuk donated a Kawai K4r! ❤

To my surprise, my Kawai K1 emulation, started out of a personal need, was a tremendous success. Something that I never expected, I’ve got tons of (good) feedback, some magazines even interviewed me and I’ve got loads of traffic on my web page.

One thing that stood out is the request to emulate the K1 successor, the K4. What prevent me from even thinking about it is that I would need to have a K4 to analyze it. I have read some documentation and the K4 is – more or less – a K1 with filters and improved samples. But as long as I didn’t have a K4 there wouldn’t be a chance for me to come up with something that is even close to a K4.

Then, all of a sudden, a mail from Evan Sirchuk arrived, saying that he would like to donate a K4r 😍 That was around Christmas. Even though I was blown away by this offer I didn’t have the time to react immediately but I replied some weeks later, I was interested of course!
Some mails went forth and back about how to ship it, customs questions (he is US citizen while I am German/EU citizen) but he obviously had a lot of shipping experience and he did it!
Some additional weeks later, I picked up the K4 at customs. Very well packaged and fully functional! Absolutely amazed by this. Of course, I sent him the shipping costs via PayPal. He didn’t even ask for it, what a great guy.

Look at this beauty:

Kawai K4r

I want to take this opportunity to say big thanks to Evan. If you want to say thanks to him, visit his web page or his Twitter. He deserves it!

K4 Emulation coming?

Most probably, yes. Hereby confirmed. The K4 is technically quite similar to a K1. It will be challenging to model the K4s filters though and how similar it will sound, I can’t give any guarantee yet, but I already have an idea how to do it.

But I cannot give any ETA. I still have some private things going on that I need to finish before I can dive deeply into the K4 and at the moment, free time is a rare good (Covid etc).

There’s one thing though that I couldn’t resist doing with the K4r. People that looked closely at the picture above might have noticed that the K4 is missing its rack ears. This is because I already opened it. 😎

I dumped the wave roms (3 chips). Luckily, they have socketed them in the K4r so this was no big deal. I wanted to know upfront if I can make use of the content, and yes, the content is not encrypted. More on that in a separate article.

Of course, you will be able to watch my progress in my K4 development blog, this is the first of many articles in this category. And the resulting VST/AU will be free, for sure 👍

Once again, big thanks to Evan Sirchuk for this great opportunity!

Nils‘ K1v: Version 1.19 released

I’ve just released an update for Nils‘ K1v, now at version 1.19. This is a maintenance release with the following fixes:

  • [Fix] Dropped midi events caused notes to be hanging or not played at all in some hosts
  • [Fix] Neither SysEx send nor receive worked in Mac AU version
  • [Fix] UI did not update if single parameter was changed via MIDI SysEx
  • [Fix] Pitch Bend changes were processed even if turned off in global settings

Please head over to the product page to download the latest version.

Download

Thanks a lot for your ongoing support! 👍

Nils‘ K1v in a browser as web assembly using Emscripten

Lately, I experimented a bit with VSTGUI again and the result is a running Kawai K1, directly in your web browser 😃

TL;DR if you want to try it: Click Here

🛑Needs a decent browser that supports web assembly! 🛑

If you want to know more about the implementation details, continue reading below.

Nils‘ K1v – VSTGUI, OpenAL, SDL2 – compiled as web assembly using Emscripten.

This idea evolved while I thought about how to release my other project, Heat Synthesizer as a native VST/AU including a UI. At the moment, it is an Android app with a small proxy VST for Windows only. The reason for not having a UI in the VST version is that I created it for Android using the native Android UI system in Java. Not an optimal solution to port it to different platforms.

To be able to port Heat Synthesizer to VST & AU, I was in need of a UI system that supports a wide range of platforms:

  • Android – Obviously I don’t want to drop support here so this is a must have
  • VST on Windows – I want to use my synthesizer directly in my DAW that I personally use, without the need to fire up my Android tablet to edit sounds
  • AU/VST on Mac – Would be beneficial if I were able to release it there, too

The Heat Synthesizer engine code compiles just fine for a wide range of platforms. I even had it running on an iPad already many years ago, just for testing purposes. But having a UI framework that covers all these platforms is not easy to find.

Actually, I recreated the UI in Unity3D some years ago. I thought this would be a good candidate to be more flexible with regards to targeting different platforms. Which is true for both iOS and Android, but Unity3D even nowadays lacks embedding support into runtime libraries so bringing it to VST and AU plugins wouldn’t be possible.

Heat Synthesizer in Unity3D

For the K1v, I’ve chosen a different strategy right from the start. Just in case you missed my development blog so far, K1v is created in C++ and the UI is made with VSTGUI. It’s a UI system by Steinberg, optimized for audio software. VSTGUI is open source and has become quite flexible throughout the years. It is no longer tightly bound any kind of existing VST SDK but also works with AU, VST3 or even in standalone mode.

What I came up with was the question if it was possible to create a fork of VSTGUI that supports Android. Knowing that I have to redo the Heat Synthesizer UI completely from scratch, my K1v project came in very handy here. K1v is a VSTGUI-based project that already compiles on a large variety of platforms (Win, Mac, Linux, both 32 and 64 bit each) that I could play around with.

K1v in Standalone Mode

Obviously, the first step was to create a standalone app of Nils‘ K1v. An Android app would be a „Standalone“ app, not a plugin. That step was pretty much straightforward and was finished after one evening.

The internal structure of K1v is that there is a generic „K1Plugin“ and a „K1Editor“ and these two are then wrapped for the different plugin platforms such as VST2, VST3 (unreleased yet) and AU.

I created an executable that opens a VSTGUI-based standalone window, embedded the K1v editor and created the K1v plugin instance.

Audio Output? MIDI?

To test the standalone app, I needed an audio output and an audio processing loop. Luckily, I solved this years ago as part of the Heat Synthesizer project. There is a simple audio output interface class with a lot of different implementations:

  • OpenSLES – Used on Android
  • Jack – Used for Samsung Soundcamp on Android. Unfortunately they stopped development and dropped support, but this implementation might come in handy on Linux in the future
  • OpenAL – I used this for testing purposes as the SDK is very small and I already knew it from game development
  • PortAudio – I added this some years ago to have lower latency on Windows
  • CoreAudio – Used to test on Mac & iOS

I opted for PortAudio and OpenAL for now as I have been able to test them directly on Windows.

As for MIDI, there is just no support included. To test that everything works, I injected a Note ON event on Note C3 at startup, should be enough. I didn’t plan to release a standalone version anyway so no need to implement MIDI here.

Emscripten & WebAssembly

You may ask why there is a web version now even though I kept writing about Android?

For me, Emscripten is an intermediate step. I didn’t want to deploy to my Android tablet over and over again to test my progress so I thought that Emscripten as a first challenge would be a good candidate to start with.

As I plan to keep most of the code in C++ anyway, both platforms are more similar than expected. Android an Emscripten are both „based“ on Linux (more or less), they have OpenGL ES as possible renderer and as I use CMake as a build system on all platforms differences are very minor during build.

Additionally, I’m not sure if an Android version of K1v is really useful. the role of Heat Synthesizer is different here, as it contains lots of online functionality (preset exchange) and can connect to a VST proxy for proper DAW integration, but as K1v is a VST already that doesn’t make much sense.
Releasing it for the web on the other hand is a nice challenge and furthermore something that didn’t exist before, at least I’m not aware of any existing VSTGUI to Emscripten ports.

Porting VSTGUI to Emscripten

While my K1v code compiled more or less directly, a lot of effort was needed to get VSTGUI up and running.

Everything I write here is based on VSTGUI 4.9, to be more specific, the develop branch at 2020.06.24 commit dc95f6a2. This is the version I used to develop the UI for Nils‘ K1v. I did some bug fixes and fixed Linux compilation errors at this time, but other than that, this is the state I’m currently working with / what the Emscripten version is based on.

The VSTGUI core code (everything that is platform independent) only had smaller compilation problems in one or two cases, but the largest issue was that I didn’t have anything for this new platform: No frame, no window, no run loop etc.

I decided to start with the Linux version. The Linux version is based on Cairo for rendering, uses X11/XCB for input handling and GDK for the main loop in Standalone builds.

Cairo for rendering

I knew that Cairo can be compiled in a way to use OpenGL ES for rendering, which both Android and Emscripten support. So i decided to fork Cairo and compile it for Emscripten using CMake.

This brought a lot of dependencies: zlib, libpng, pixman, libpixman.

More projects that I had to fork. Some of them already had CMake build scripts, which was great, for others, I created CMake build scripts from scratch. It took some time but worked eventually.

Although the web assembly based executable linked fine, I still had a lot of work to do. I didn’t solve the standalone part yet, i.e. the window handling and mouse & keyboard input.

I created some stub classes to be able to test it. At last, I heard the K1v preset IA-1 Ahh playing Note C3 in a browser window, yeah 😎

Using SDL2 to have a render target for Cairo

The next problem I had to solve was to define some sort of „window“ as that is what a standalone app in VSTGUI is based on. The problem is that you do not have any sort of window in Emscripten, as you’re running in a web browser. You get a canvas that you can paint on, that’s it.

Luckily, the Emscripten team already solved this problem by porting the SDL library to Emscripten. This was great news as the SDL library also supports Android.

I spent quite some time connecting an SDL „window“ to Cairo. I wanted to give hardware acceleration to Cairo so I compiled Cairo with OpenGL ES support and created a GL Surface in SDL. Unfortunately, I had to drop this idea for Emscripten as only a subset of OpenGL ES 2.0 is implemented and Cairo makes use of these missing features (for example pbuffers).

So instead of using the GL based backend, Cairo runs in software at the moment. Nevertheless, I was blown away when I saw parts of my UI for the first time:

Font Support

As you might have noticed, there are no texts in the UI. The reason for this is that the Linux build of VSTGUI uses fontconfig to enumerate the available system fonts at startup. I had to comment out that whole code block as there is no fontconfig support in Emscripten and adding this library doesn’t make sense as there are no „system fonts“ available anyway. So instead of using fontconfig, I did the following:

I created a virtual file system for Emscripten at compile time with a folder named „fonts/“ that contains all fonts that I need for K1v. These are not many and the resulting data blob is around 1Mib in size only.
At load time, this font list is built by enumerating through all files in this folder. Then, I load the files with FreeType to query for the family name and style name to finally rebuild the original fonts list that VSTGUI uses. This worked out pretty well and is completely customizable as the available fonts depend on what you put into the virtual filesystem. No hardcoded hacks were necessary.

Web assembly version of K1v with libcairo rendering fonts
Input Handling

As I had the SDL library, adding input handling was pretty straightforward. I use the SDL for mouse, keyboard & window events. I also use the SDL for timers.

Missing Features

The project is highly experimental and in a very early stage. VSTGUI support lacks the following:

  • file selector is not available
  • no alert boxes
  • no support window styles as there is no real window
  • no drag & drop
  • no tooltips
  • no clipboard support

The web version of Nils‘ K1v doesn’t currently support:

  • State is not preserved, if you reload the page, you’re going to have factory patches again, no matter what you edited before
  • MIDI – The only possible input is the virtual keyboard on the web page
  • Load or Save of files due to missing VSTGUI file selector

Most of the above could be implemented easily. Another thing worth mentioning is that I don’t currently use AudioWorklets as it seems to be quite cumbersome for now to get them running in Emscripten. The audio output is done by OpenAL and everything is single threaded. You can expect some audio pops & clicks here or there, it depends on your browser & computer, mostly noticeable when large UI parts are redrawn. Comments about how it works for you would be nice.

Future Work

After finishing the port to Emscripten, its time for some cleanup work, obviously. After I will have finished cleaning up the VSTGUI parts, I’m going to make my VSTGUI fork open source. I might decide to do a pull request, maybe Steinberg is interested to integrate official Emscripten support? Who knows.

To summarize, I had to create implementations for the following VSTGUI interfaces to make VSTGUI work with Emscripten:

  • VSTGUI::IPlatformTimer – SDL timers
  • VSTGUI::IPlatformFrame – SDL <=> Cairo frame
  • VSTGUI::Standalone::Platform::IWindow – SDL Window
  • For standalone mode, an SDL application which drives VSTGUI::Standalone::Detail::Application
  • Some groundwork such as an SDL run loop to drive redraws & inputs.

These are all great preparation steps to have an Android port of Heat Synthesizer. I’m going to continue this journey with the K1v project though, as I want to proof that my concept works before doing a complete UI redesign of Heat Synthesizer with VSTGUI.

I’m confident that the Android version of the SDL/libcairo combination will support hardware accelerated rendering, which is even more important on mobile. As Android has full OpenGL ES 2 support, this should work fine.

I’m going to post updates on this topic. Leave a comment and tell me what you think 👍

Nils‘ K1v: Version 1.14 released – Multi support!

I’ve just released version 1.14 of Nils‘ K1v – The Kawai K1 emulation VSTi/AU.

Biggest change is that it now also supports Multi presets. I added the 32 factory Multis and all Multis from the ROM cards, resulting in 384 Multi presets in total.
As a sum, Nils‘ K1v now contains 1352 presets.

Nils‘ K1v – Multi Play Mode

Of course, Multis can be edited, too. To add all of the new features, I modified the UI slightly. The Source Mute buttons have been moved to the Single Edit page, making space for the new Buttons MULTI and SYSTEM.

I’ve been able to fit four Multi sections on one page, arrow buttons allow to switch between sections 1-4 and 5-8.

Multis work as they do on the Kawai K1 hardware. Up to eight Singles can be combined in various ways to create either rich layered sounds or multiple zones on the keyboard.

The only difference between a K1 and K1v is that in Poly Mode VR (meaning variable), the polyphony is unlimited, while it was still limited to 16 or 8 voices in total on a K1 hardware.

Nils‘ K1v – Multi Edit Mode

The SYSTEM page is a new page that allows to change global parameters, basically it’s a copy of the K1 Midi Settings and supports specifying a Midi receive channel (previous versions always ran in Omni mode) and to disable Program Change processing, Sysex & more.

Global settings are saved as part of the DAW project.

Nils‘ K1v – Global Settings page

Besides the improvements as pointed out above, some additional things have been added, such as cursor key preset navigation (Hallo Jürgen!) and of course, bugs have been fixed, too. The full change log can be found below.

Download the new version from the K1v product page.

Changes

  • [Fix] Wrong number of presets (832 instead of 968) were reported to plugin hosts
  • [Fix] Midi notes could get stuck in some cases
  • [Fix] Rounding issue in fixed key note number drop down menu that caused note B0 to be displayed although note C1 was selected
  • [Imp] K1v now supports Multi presets. All factory Multi presets have been added for all factory banks, making up a total of 384 Multis, or 1352 presets in total
  • [Imp] K1v now has a settings page to allow to specify the Midi receive channel, disable/enable receive & send of SysEx and more
  • [Imp] Midi receive channel can now also be modified by sending an Omni-Mode-Off control change from a specific Midi channel.
  • [Imp] Added ability to navigate through presets with cursor keys
  • [Imp] Code optimizations to reduce overall CPU usage

Nils‘ K1v: Version 1.13 released

I just released Nils‘ K1v version 1.13.

The most noticeable change is that I have added all 200 PHm Pop Synth Module presets to the plugin, resulting in a total of 968 Singles.
As the list of Singles became even larger, I reworked the play mode section to make Single selection easier. There is now a dropdown to allow to select a bank directly and there are additional navigation buttons.

Nils‘ K1v – new Play Mode section

Another interesting change for some people might be one accuracy fix: Key Scaling =>Envelope Time didn’t modify Decay but only Attack, causing some Singles to sound incorrect.

More details & all fixes and changes can be found in the change log excerpt below. The new version is available for all platforms and can be obtained from the Download Page

Changes

  • [Fix] Drop down menus were hard to read on Linux because of the font being too tiny
  • [Accuracy] Key Scaling => Envelope Time modulation did not affect Decay but only Attack, causing some Single to sound incorrect when compared to the K1 hardware.
    This change fixes the Single ‚KillDa Mix‘ and others, mostly Pianos.
  • [Imp] All 200 PHm presets are now part of the plugin, causing it to have 968 total built in presets.
  • [Imp] Single selection screen has been reworked, for easier navigation it now includes a dropdown to select the Bank and has more navigation buttons.
  • [Imp] Plugin Logo has been reworked to match the K1 hardware logo. Furthermore, the „KAWAI“ logo has been integrated as Kawai gave official permission for the plugin.