Cakewalk and the K2000 ---------------------- By: Keith Cowgill Respond to: kcowgill@infinet.com I have, on many occasions, been required to transfer sequences prepared in Cakewalk to the K2000. Usually, I need to do this to take my MIDI rig and sequences to a studio in which there is no PC. Exporting from WinCake Professional ----------------------------------- In WinCake Professional, you have the option of specifying the type of .MID file (Type 0 or 1) you wish to export to disk. Look at the Save As dialogue box when you save to a MID file. You should see a little button marked Options. Click that. You'll get a new dialogue box allowing you to specify the type of .MID file you are saving. For our purposes, we want Type 0 (Single Merged Tracks). However, the translation to .MID file via Cakewalk is not perfect. I have discovered three problems in doing so that you might want to be aware of. 1. Strange bank change commands For one, Cakewalk seems to do weird things with the bank and patch settings in the Track Pane--or at least the translation of whatever CakeWalk does by the K2k is slightly dysfunctional. If you declare your patches/programs and banks in the track pane, *and* in the events list, then all of this information will find its way into the events list on the K2k. And often, for reasons I haven't yet figured out, some of the bank numbers get really hosed. When you examine the transferred song in the K2000's sequencer, you'll see much duplicated information and some really strange bank change numbers. For that reason, whenever I get to the point where I export, *I get rid of all patch and bank information in the track pane (i.e., set them to -1).* I make sure that all of my program and bank change commands appear in the events list only. That will leave me with one spurious bank command in every track. Say for example, I'm using the Real Drums program (Bank 0, Program 64). If I have that information entered in my event list, and have no bank or program listed in the Cakewalk track pane, then when I export the .MID file I will wind up with two Bank 0 commands in the K2k song followed by one Program Change 64 command for that track. (Also for reasons I don't understand, one of the "Bank"s is spelled in upper/lower case and the other is all caps. Try it!) I delete one of the Bank 0 commands, and I'm ready to go. This is true for every track. 2. Minor timing anomoly The next anomoly is that the events don't always fall where you'd expect. In Cakewalk, I'm usually set to 120 ppq, whereas the K2k is 480 (like I said, I'm doing this from memory, so it may be 400-something else). I've had events at, say 80:1:000 in Cakewalk wind up at 79:4:479 or something like it. It isn't that big a deal on playback but it can be annoying if you are a neatness freak. 3. Major Program Change bug. I don't know why this bug hasn't been noticed yet, because it can be quite annoying. But it wasn't until I verified it with David Fox in May '95 that he was aware of it. Essentially, the bug is this--the K2000 (through at least ROM version 3.18) cannot save a program change number greater than 110 to disk. It doesn't matter what your PChgType is set to. If you save your sequences to PRAM only (a dangerously optmistic technique), you won't notice the bug. If you save and load them from disk, you might. I noticed the bug because I leave the PChgType set to Extended, and use my K2000 to drive other modules, some of which are of the older 0-127 type. In Extended mode, the K2000 will not itself recognize Program Changes above 100, but, if they occur in a sequence, will transmit them just fine. Therefore, Extended mode seems to be the best for my situation--allowing me to use all of the K2000's banks while driving all of my other modules as well. However, assume that I have a Program Change of 115 in my sequence. If I save the sequence to disk and then reload it, then the Program Change number will have changed to 15. As I said before, this will happen *even if* your PChgType is set to 0-127. So why does this happen? I inserted a Bank Change command of 0 prior to the Program Change of 115, saved to disk and reloaded to see what would happen. In the retrieved sequence, the Bank Change command had changed to 1 and the Program Change had changed to 15. My theory, then, is that the K2000 programmers at one time created an error-correction routine that works either on disk saves or loads. This error-correction routine reads all program change commands. When it sees one above 110, it will try to subtrack 100 from the Program Change command and increment the Bank Change command. If no Bank Change command exists, then only the Program Change command is altered. I have recommended to Kurzweil that this routine be dropped altogether, as it serves no useful purpose in any event. In the meantime, if you are using your K2000 in a situation such as the one I described above, be sure to make a note to yourself where the measures and tracks in which your greater-than-110 Program Changes occur. It might save you a little time and embarassment when you get to the studio.