Korg Triton Pro


Introduction

In September 1999, I bought myself a Korg Triton Pro synthesizer workstation. I'd long wanted a working replacement for my older, basically-mothballed music setup, which was a Mac SE/30 (which needs fixing), a MIDI interface, a Roland MT-32, and a Yamaha Clavinova (which my wife often uses to practice her singing).

I'd actually planned on getting a Korg Trinity, but just when I decided it was finally time, the Triton came out, as I noticed in the issue of Keyboard Magazine that had just come out.

Mostly I want to get back into playing with instrumental music stuff, now that I've sung for many years as a means to more intimately acquaint myself with the ins and outs of music. (I've long been a music fan, but wanted to understand better what was going on "underneath the hood" of music.)

Having a workstation instead of a MIDI setup means I don't really have to include a computer of some type (PC, Mac, GNU/Linux box, whatever) in the setup. I already work with computers much of the time, didn't want to have to learn another new OS like Windows or MacOS (which would seem like new to me after all these years of sticking with version 5 or whatever is on our ancient Mac SE), and didn't want exploring free-software sequencing and notation programs to be the gating factor on my doing musical work and play.

As a workstation, the Korg product line seems to offer the most viable interface available (note stress; I'm sure better interfaces are possible, and can only fantasize about the Korg's internal software being free-software a la Linux). The Trinity and Triton have LCD screens, somewhat akin to those of the classic Macs. Enough for serious composition of new works? Hardly, but I'm not ready for that yet anyway, if ever. I've always got the computer as a potential upgrade path, thanks to MIDI, of course.

In the meantime, the interface is adequate for the kind of stuff I'm doing now: exploring chords and chord progressions, entering music our chorus is planning to sing to use for practicing, exploring the sound architecture, and so on. (My wife reports being thoroughly enamoured with the ability to practice to the sequences I'd recorded onto MiniDisc for use while on vacation. These were based on the five pieces, of eight we sang in our November 1999 concert which I recorded "straight" as well as with her second-alto part "prominent", meaning with the other parts mixed way down, ditto for my first-bass part. Both of us singing to the second-alto versions works, since it helps me make sure I can find the right notes even when I can't really hear my part in the instrumentation, a good challenge.)

I've added the EXB-PCM02 and EXB-MOSS boards to it so far. The MOSS board is particularly cool in its physical modeling of brass sounds, as evidenced by using different velocities as well as the ribbon controller.


News

2000-12-05

Finally "resolved" my file-storage problem. Wasn't willing to puts lots of time and energy into creating files via my Korg until I could be sure of being able to make reliable backups, etc.

Since the Korg can't yet properly format or write to CD-RW disks, I bought an external SCSI ZIP 250 (250MB) drive, which works great on the Korg.

That solved one part of the problem. Spent a fair amount of time moving all my data, plus saving internal Korg data, to a ZIP disk.

But how to back the data up? (I'm a stickler for backups.) My Pentium II has SCSI-II Ultra support for external SCSI devices, which I believe won't work properly with a non-Ultra external SCSI device like the ZIP. (Besides, its SCSI adapter can't handle external SCSI devices without my first disconnecting its internal 50-pin connector, which I currently use for both a CD-R and CD-RW drive, or its internal 68-pin connector, which is used for the two primary 4GB hard drives. I could use just the external CD-RW drive I bought for the Korg, disconnecting the internal CD-R and CD-RW drives, but decided to not go down that road due to uncertainty regarding the workability of a 50-pin external SCSI device on a 68-pin external SCSI Ultra bus.)

Since there's no internal SCSI ZIP 250MB drive available (that I could find), I considered using a different computer for its external SCSI non-Ultra (50-pin) connection, then using sneakernet (or a real network) from there. Not exciting. I don't think my Pentium II has any IDE/ATAPI support, so that sort of ZIP drive was not considered. Further, a USB ZIP drive could physically connect to my system, and presumably work fine under Windows, but, being newer technology, USB support is still in its early days of support, especially under GNU/Linux, the operating system I run most of the time.

So I decided to buy the parallel-port version of the ZIP 250MB drive, which I did last night, and it works fine under Windows (just backed up my Korg disk to it)! I believe it'll work under GNU/Linux as well, since I came across some web pages on the topic while searching for SCSI ZIP viability under Linux awhile back. Maybe someday USB support will be "all there", and its ability to support "hot-swapping" seems interesting, but not critical for me at this time. Besides, the parallel-port ZIP drive cost about US$30 less than the USB version, even though the box (and drive itself) was bigger and heavier!

In the meantime, besides housekeeping stuff on the Korg not requiring backup, haven't done much with it, besides sketching out musical ideas and inspirations on paper with its help. (I've also used our old Mason-Hamlin upright piano; it never needs to go through a power-on cycle and doesn't need an amp. ;-)

In the meantime, I've given up on relying on the Korg's floppy drive, opting to not get it fixed before the warranty period expires. Just didn't want to be without it for two to three weeks, and realized any serious work I was planning would require much more than a floppy for saving, for transfer, and for backup, anyway. I'm quite comfortable with the decision -- for now!

2000-08-06

While loading the TNFP-00PUS and TNFP-01P disks to check out the demos with sampling (the GOSPE00.KSC file or whatever it's called, containing the samples of gospel phrases, being on the second disk), the floppy complained and the Triton subsequently put up an error box on the display, just like it's been doing for longish writes.

And, just as with writes, leaving it alone for awhile, maybe removing and reinserting the disk so it can get a "fresh start", was enough to let it finish.

I'm fairly convincing this is not an OS bug. The Triton OS, not even having a built-in "wall clock" (you have to set the current date/time manually, important if you want correct information on files you write to disk), almost certainly doesn't know or care that 5 seconds or 5 minutes or 5 hours has passed since you last tried to read or write the floppy.

More likely, something in the floppy controller or the mechanism itself is going out of spec, probably driven there by the modest amount of heat generated by being "worked". Since I keep my office at around 70 degrees F, it's unlikely this is an environmental problem.

2000-08-06

About four weeks ago, I ordered the EXB-SCSI board, and it finally arrived yesterday. Apparently there was a problem with the order and it had to be re-entered (by Wurlitzer's in Boston, where I bought the workstation), but they didn't call me until it finally came in. (I had called them two or three times in between, trying to find out what was going on.)

Because I couldn't save much data, I put aside working on the Triton for most of this period. Did find out about a nearby service center that could fix the floppy, but I'm not sure whether to take it in, be without the synth for two or so weeks, and get it fixed while under warranty, or to get the new CD-RW I ordered (at the same time as the EXB-SCSI board, though the CD-RW arrived over three weeks ago) up and running as a fully functional read/write/transfer-to-PC subsystem and stop worrying about the floppy.

The EXB-SCSI card has a SCSI connector that turns out to be a bit on the "unique" side -- a (female) DB25 connector, neither Centronics (huge 50) or "Micro" (small). The cable that came with the CD-RW drive, designed to connect its female Centronics DB50 connector to a female Micro DB50 on the other end, didn't fit, and the EXB-SCSI card itself came with no cable. So I bought an adapter (male DB25 to female Centronics 50), called a "ZIP Drive SCSI Adapter", as well as an ordinary Centronics 50 Male/Male SCSI cable. These hooked up quite readily.

After dealing with connecting up power to the CD-RW, I powered it on, then the Triton, as directed by the EXB-SCSI docs. (Powering off is done in the opposite order. Well, this order makes sense, I guess, for how SCSI devices work. But I'm "historically nervous" about it, since I'd rather any writeable-storage device not be on when its "master" powers on or off, since that sort of thing has, in the distant past, resulted in the master's -- the computer's -- burst of random noise on the bus being interpreted by the storage device as a command like, oh, say, "wipe out all data".)

Turns out that to get the Triton to recognize a SCSI device, one needs (in "DISK" mode) to select the "Media Info" tab and then pull down and select the "Scan SCSI devices" menu item (going from memory here -- it's all powered off right now). Then one can choose among the SCSI devices it found as well as the floppy via the indicator with the pop-uppable arrow to its left, just as one changes patches in "PROG" mode, etc. (Having become accustomed to the Triton responding to my inserting a floppy then touching the screen by resetting its "view" of the floppy and otherwise ignoring the touch, I expected it'd automatically "recognize" the CD-RW or CD-R media that I'd inserted in the drive when I subsequently touched the screen. The designers chose to have the user directly control exactly to which device the Triton is presently attending, which probably helps reduce the chance of the poor thing seizing up in the middle of playing back a sequence being recorded to a CD-R because the user thought he could insert a new floppy while that was going on and then take a look at a different set of mixers or something.)

Sadly, the Triton doesn't know how to format CD-RW disks, and until they're formatted (however that's done -- haven't tried it yet), it sees them as "unformatted" hence unwritable: all menu items when "Save" tab selected are disabled. (Of course, the Triton offers a "Format" menu item under "Utilities" in "DISK" mode, but it fails with an error after you approve a "Full format", and a "Quick format" is insufficient, since no format has yet been done on a virgin CD-RW disk.)

So, until I get the "sister" internal CD-RW drive I ordered (at the same time as the external one) installed in my Pentium II and figure out how to format CD-RW's, I still can't save a substantial amount of data from the Triton! I'm not even sure Red Hat Linux 6.2 fully supports CD-RW devices, though for the rare event of formatting a CD-RW disk, I can probably live with rebooting into Windows 95, after installing the pertinent software provided with my CD-RW of course.

The good news is that the Triton definitely can read from CD-R disks inserted into the CD-RW drive. I verified this by popping in one of my CD-R disks (one volume of a backup of my Pentium II a few months ago) and verifying that I could move about the directory structure. (I doubt it has any .MID or other files the Triton would recognize on it, so I can't actually load anything from these CD-R's, but I can "open" directories and view their contents.)

So the SCSI interface itself seems to work fine as far as reading data is concerned. And maybe writing will work too. I suspect even formatting a hard drive would work, but formatting a CD-RW definitely doesn't. Will visit the Korg web site again soon to see if they've got a new version of the Triton OS available that might help with this. (I even wonder if 2.0.0 "broke" large writes to floppy, rather than the floppy itself breaking?)

But I am enjoying the new EXB-PCM01 card. Great sounds, mostly piano, electric piano, clavichord, harpsichord. The key-off clicks in the Harpsichord 8' and 8'+4' patches are quite convincing! Definitely inspirational, and we all know how much the world desperately needs some 21st-Century harpsichord music. ;-)

And I've finally resolved my past confusion over the relationships between how a "bare-bones" Triton uses Program/Combination banks A, B, C, and D, and how the expansion boards (PCM01 through PCM04 now, two of which can be installed in a given Triton at the same time) employ them.

The bare-bones Triton comes with a "full load" of data for Program and Combination banks A-D. (Apparently it initially offered less than complete C and/or D banks as Programs and/or Combinations, because my Triton came with a "replacement disk" to be used in place of one of the two installation disks. Haven't looked into this further.)

Each of the EXB-PCM boards (at least, the two I have, 01 and 02) comes with one bank's worth of Programs and Combinations. However, it provides these encoded as two separate collections, one that puts everything in the C banks, another that puts everything in the D banks.

Now, the underlying oscillators, samples, whatever they're called, will have the same "address", or encoding, within the individual programs that specify them, regardless of whether a board is installed in one or the other slot. (If the board's missing, the Triton doesn't sound that program until the oscillator selection is re-established to be something that exists.)

So even though my EXB-PCM02 board is installed in the first slot and my EXB-PCM01 in the second, the programs that accompany them identify the oscillators these boards contain by board id rather than by slot number.

This is in contrast to how the sampler works. It identifies samples by RAM slot. Not a big deal, since one normally doesn't manage to swap RAM cards around while the computer remains powered up. In theory, though, if the Triton offered the kind of "hot-swap" technology some high-end, or high-availability, computers offered, you could swap 'em around to your heart's content, and, still in theory, since the RAM cards themselves would have static RAM (SRAM), they wouldn't lose their little minds when they lost power. But you'd have the problem of all those nice Program Bank E samples now programmed incorrectly -- you'd have to manually change each one to point to the new RAM bank instead of the old!

So I've chosen to load EXB-PCM01 Programs and Combinations to the corresponding C banks and EXB-PCM02 ones to the D banks. This overwrites the original C and D bank information provided with a bare-bones Triton. (It is these original banks' programming for which I can find no documentation. I'd written there was no info on Banks C and D here on this page, based on something I'd read or on not finding the info at one point, but I've since realized that I do have information on Banks C and D as programmed by the floppies shipped with the EXB-PCM01 and EXB-PCM02 boards. It's the programming info on Banks C and D for a bare-bones Triton I can't find right now.)

Then, I've loaded all the EXB-MOSS data. This loads up not only Program Bank F, it overwrites the first half (00 through 63) of Combination Bank B.

All of the overwritten information is accessible on floppies, of course, and it's now clear to me that Program Bank E is available for use just as A-D. There's no real difference I can see! So if there happened to be a bunch of patches for the bare-bones Triton that I wanted to use but had overwritten, I could load just the ones I want -- as many as 128 -- into Bank E. (There's no Combination Bank E, just Banks A-D.)

Which raises an interesting question: given that Bank E is, internally, no different than Banks A through D, why is it also designated "SMPL" on the keyboard itself, and why does the manual describe it as being "for samples", when any program in Banks A-D can use samples (RAM-based oscillators) and any program in Bank E can use any internal (ROM-based) or expanded (EXB-based) samples, or oscillators, as well?

My theory is they set it up this way to make it more natural that people will assign patches in a manageable way. Knowing that all RAM-sample-using patches are in Bank E makes it easier to know to save both sample RAM and all the patches that use them at once, and to restore them both at the same time. It should make keeping a given collection of samples together with the voices that use them.

After all, the sampler can contain any of a nearly infinite variety of collections of samples, therefore the patches that use them can be of similar variety.

So, whereas the Triton itself helps manage the comparatively few EXB expansion boards, and since adding or removing such boards is comparatively rare, the potential for more frequent changing of sample RAM makes it necessary to have it be easy to frequently change the "slots" used for patches that use sample RAM.

Keeping sample-using patches in Bank E is probably better than sprinkling them throughout patches A-D and/or sprinkling non-sample-using patches into Bank E. Even if you could dynamically load a bunch of sample-using patches into "free" (unused, or ineffective due to no longer having pertinent samples available) slots in Banks A-D, you'd still have the problem of existing songs, or sequences, which identify "instruments" by Program Bank and slot number, having to be changed accordingly.

(Yes, ideally, we'd have a high-level way of managing songs, instruments, combinations, oscillators, samples, etc. It'd provide for identifying things by filenames, or even URLs. Software would then automatically manage the task of finding free slots for whatever was needed at the time, just as it does now for files versus low-level disk block numbers and for programming variables versus RAM (core) addresses. Maybe I'll design and implement such a thing -- but probably only after someone ports Linux to the Triton. ;-)

The upshot is that, yes, you can use Bank E for "overflow" stuff when you don't want to find "unused" programs, but if you're going to be using the sampler, it's probably best to "bite the bullet" and use Bank E for only sampler-using (RAM-oscillator-using) programs. In the long run, you'll probably find it easier to keep track of things that way.

[Note: someday I expect to move most of the above explanations into a suitable location on my web site. In the meantime, based on the "hits" I'm seeing on this page and the email responses I've had, it seems likely that it's helpful to a few people to share my "stream of consciousness" in this format at least.]

2000-06-17

The floppy drive is failing. It can write (or format a disk) for only so long before giving up with media errors. First noticed this yesterday, but have managed to forge ahead and save everything without any loss of important data. (Thankfully, the Korg's software is well-engineered enough to provide opportunity to insert another disk and continue saving files where it left off, when trying to save multiple files. At least it appears to work well!)

I'd already decided to order the EXB-SCSI board for better storage facilities, and this has pushed me into doing it right away. While at it, I've ordered the EXB-PCM01 extension board, which has been widely recommended by several Korg Triton enthusiasts with whom I've corresponded -- it adds a variety of keyboard sounds, from what I can tell.

Meanwhile, I've enjoyed learning how to use the sampler, continued entering new little music snippets I've come up with (no complete songs yet though!) as well as making previously entered sequences, which I've used to rehearse vocal (solo and chorus) works I've been performing, available to others as General MIDI sequences, which I convert from native Korg format and instrumentation using the Korg.

2000-06-13

Figured out how to record tempo changes dynamically. After hitting REC/WRITE, then switch the Tempo mode from AUTO (or MAN) to REC, and proceed from there. Page 46 of the Parameter Guide explains this.

Upgraded to OS version 2.0.0. Didn't notice any bug fixes. Couldn't read one of the two PDF files in the upgrade, due to it being encrypted, according to the various "pdf" tools available on my Red Hat Linux 6.1 system.

Finished "neating up" one of the songs my wife and I used for practice in the fall of 1999. It's Pachelbel's "Jauchzet dem Herrn", a beautiful piece even with the singers (and the words they sing) replaced with synthesized brass and woodwinds!

2000-06-12

Minor fixes, add a link or two. Am presently downloading the latest version of the OS, which I hope will fix a few of the bugs I've run into. (They're mostly minor, thankfully.)

1999-11-17

Debut of this page.


Bugs

I've found a few bugs (well, possible bugs) in the Korg so far. Going on my old notes, which need fleshing out, here they are:


What's a Workstation?

From what I can tell, a synthesizer workstation combines the synthesizer module itself (which produces the sounds) with a keyboard and a song memory system (usually called a "sequencer"), plus a few other features (like a mixer) as necessary.

With a workstation, one can compose, arrange, edit, produce, and perform a typical 5-minute pop song, at least, and play it directly into a recording device (such as a tape or CD recorder).

MIDI allows each component listed above to be a separate hardware component, and the personal computer revolution has combined with MIDI to allow any of those components (except the "hardware" ones, like the keyboard) to be done on a PC.

So a workstation combines components that could be separate into a single box, usually for convenience, especially the case for me at this time. (Kind of like, in audio, a receiver combines a power supply, an amplifier, and a tuner, each of which could be separate. And, for "power users", they often are, just like with synthesizer setups.)

My Korg workstation, plus headphones and a place to plug it in, therefore is a pretty complete setup for doing all sorts of musical things.

Most of my expansion needs could be met by getting a MIDI interface for my PC (which normally runs GNU/Linux, but can dual-boot into Windows if necessary) along with whatever software I need at the time.

Since the Triton comes with a built-in sampler, the only other hardware I'd probably ever need to do the most wonderful stuff I can currently fantasize about is a digital mixer (to handle acoustic parts, to mitigate the 16-track limit, etc.), but even that can, in theory anyway, by handled by a sufficiently muscular PC.

Why buy a distinct, custom component when a PC could do the work? For reasons similar to why even very smart and penny-wise people have FAX machines, such as, when the PC is down or busy with something, it's nice to have a dedicated machine. It's also somewhat easier to track down certain sorts of failures.

In my case, it's also nice to sit at a keyboard and be productive without ever feeling like I'm supposed to check for email on it. (Just watch, Korg'll add an email mode. ;-)

And since I'm hardly a keyboardist (in the musical sense), I really need the kind of note-by-note editing that a decent sequencer (like the one on the Korg) offers, but on a music, not computer, keyboard.


Copyright (C) 1999, 2000 James Craig Burley
Last modified on 2000-12-05.