During past weeks, I worked a lot on the User Interface. For faster iteration times, I did the layout in Unity3D and wrote an exporter to create an xml and bitmaps for VSTGUI. This allowed me to do adjustments to the layout very quickly:
The first layouts that I posted some time ago had to get some updates. I forgot a section to set the name of a Preset and the Play mode page had to get some additional buttons, plus a search box to find presets quickly.
Some people pointed out that it would be better to have all sources on one page for faster editing. I tried it, but it just didn’t fit on one page properly. I didn’t want to ruin the design completely and the editing functionality is already really good in my opinion.
For the emulation engine, I had to do some minor finishing touches and fixed some bugs:
Ring Modulation didn’t behave correctly when being set to reverse mode
Fixed ring modulation caused envelopes to be applied twice, resulting in wrong decay & release behaviour
Implementation of Poly 2, Poly 1 and Mono modes was still missing
K1v will now correctly respond to Sysex messages, just as a real K1 does
Support to mix Source levels with the Joystick
Some code fixes to support 64 bit compilation
Midi: Pan, Main Volume, Program Change including Bank Select, Hold Pedal, All Notes Off
State serialization to make it possible that the state is saved as part of a DAW project
I’ve got many questions about the VST plugin, so I wanted to give some more & updated information about it.
VST Version & Operating System Support
Initial plugin will be a VST 2.4 plugin (VST3 later)
Two versions will be available from start, x86 and x64
As I don’t own a Mac and I’m not familiar with Mac programming, I can’t port it easily to a Mac AU. I have a colleague that could help out here, don’t expect it too soon though.
Instead of the original voice limit of 8/16 voices, the plugin will have unlimited voices
It will contain the K1 factory bank, the K1-II factory bank and all ROM cards, giving a total of 768 Single presets. Multi support is not planned for the first version.
Full editing capability (see UI section below)
SysEx import & export, which will basically make the plugin become a possible editor for a real K1
All Single parameters can be VST automated + the Source Mix Stick will get two automatable parameters
The plugin will support all MIDI messages that the real K1 supports such as program changes, Midi CCs, receiving Sysex is supported as well:
All Data Block Dump (i.e. a full Bank of Singles)
Single Data Dump (one Single)
I extended the MIDI feature list compared to a real K1 to now include support for the following additional midi messages:
MIDI CC 10 (Panning, which the K1 did not support)
The K1 Source Mix stick will be mapped to two Midi CCs
Bank Select – Used to switch between the various factory banks and ROM cards. As usual, Bank Select must be send before a Program Change
Pitch Bend wheel will use full precision (K1 is limited to 8 bits)
Most of the Single parameters will be mapped to Midi CCs so they can be edited via an external Midi Controller
I’ve received a lot of feedback for the very first UI mockup, which wasn’t even finished. I continued working on it to clarify some things. My intention was to have something that someone instantly recognized as being a K1. But of course, at the same time I always wanted the UI to be functional, including full editing capability.
Below are the two editing pages (Common + Source) and the „Play Mode“, where you can browse through the banks / singles.
Hope this clears things up a bit 🙂 And yes, the VST window will be resize-able, maximum resolution is 2560 x 1440
A new audio demo is ready. I kept a lot of the old one but added some additional Singles from the ROM cards and a Vibraphone to demonstrate an AM preset.
Obviously, a big change is that the samples are now from the original K1m Wave ROM. Other than that, all the modulations are now properly implemented and I did a lot of A/B testing to match my real K1m. Without all of this, most of the new sounds (many of them being FX) wouldn’t even work.
Some reverb & EQ has been added, everything else is just the K1 VSTi
0:00 iA-5 Return Home
0:22 Water Drama (K1 ROM card / Kawai PHm)
0:38 iB-3 Jazz Harp
0:46 ID-3 Vybes (Amp Mod demonstration)
0:56 IA-5 Visitors (K1 aliasing demonstration)
1:11 Hold a Key (K1 ROM card / Kawai PHm)
1:19 IA-3 String Pad
1:29 IC-7 Terminator
I played around with some UI mockups. Completely work-in-progress of course. The lower section will look different to a real K1m as I want a better editing of course, with envelopes being displayed graphically etc.
After I had finished dumping & integrating the waveforms, I concentrated on the parameter side again. I finished the implementation of all parameters that make up as Single and browsed in the Factory Presets and the ROM cards to do a lot of A/B comparisons to match the original K1. For now, I’m really happy with the sound (new Audio Demo in next post).
Some details about some of the things that I’ve implemented lately:
Ring Modulation (aka. AmpMod S1S2 / S3S4)
This was pretty much straightforward, what the K1 does is that it multiplies one source with another. The only thing I needed to test here was what happens if a source is muted and what is different when the AmpMod is set to S2>S1 vs REV.
Not really a big deal but as I have been asked if AM would be implemented. Yes, of course.
I had to do another round of Velocity Curve adjustments. The problem that I was facing is that, if I record all velocity values from 1-127, I get a result that I can easily transfer to an internal table, but the problem is that the recording is affected by the envelope level itself, which is not linear and which I already map.
It would be nice to just use the velocity levels directly for the envelope level, but that doesn’t work because the velocity curves are used to modulate some of other things, too: The envelope attack duration and the autobend depth.
If I would use velocity curves here that are affected by the envelope level already, it gives wrong results. As I didn’t have any change to find out what the velocity values are directly, I used the envelope level values that I recorded and adjusted them in Excel to be a bit closer to the graphs that are printed in the manual. Unfortunately, the graphs in the manual do not match the real results in the recording at all, so I had to do a lot of A/B comparisons to get it right.
Below is an image of my Google Spreadsheet, forgive the bad names for the curves 😎
The Autobend implementation in itself was not that complicated, but the autobend depth value had some challenges. If the autobend depth is at maximum or minimum (+50 or -50), the range is exactly one octave up or down. But a value of +/- 25 is not half of an octave, the mapping is completely different. Large values have a much larger effect in the rate of change than lower ones.
I figured out that the mapping is identical to the vibrato depth, which can modulate +/- one octave as well, so I finally had something I have been able to reuse.
I solved the vibrato depth curve some time ago already. I used an LFO set to square and recorded all depth values from 0 to +50 and wrote down the frequency changes as note numbers. I think I didn’t post a picture yet, so here we go:
Autobend and vibrato is not very well explained in the manual, the only thing you get out of it is that the vibrato is delayed by the autobend time (whose mapping is identical to the envelope delay time, by the way).
But its not that the vibrato just starts immediately with full strength after the autobend time has elapsed, its fading in. Luckily, the fading is linear so it was easy to implement. After some further testing I came to the conclusion that the fade in duration of the vibrato is twice the autobend time.
Key Scaling Curves (KS Curve)
The key scaling curves are another thing that I had to record to figure out the mapping. What I found out is that every KS curve is within a range of Midi Notes C1 to C6 (at max, some of them are shorter).
I recorded all of them and did the mapping to note transposes in Excel again. The curves look like this:
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.