Piano World Home Page Forums Our Most Popular Forums Digital Pianos - Electronic Pianos - Synths & Keyboards Korg Kronos, 4GB pianosample in hardware!

And it's a sampler that can load SF2 and Akai formats.

I wonder if their PA series arranger keyboards or their high end pianos will use the same technology in future...

This seems to be an interesting thing about technology. Over in the Motifator forums, this new Korg keyboard is likewise being discussed. I have to admit that it is a "game changer". However, its presence does not change anything about the keyboard workstations we already own. They still do what they do, and therefore the reasons that we chose the specific models we chose, does not change.

I own a Motif XS8. The Motif XF is the newer version of a fine workstation. I am not compelled to get one because the XS still does what it did when I got it. It sounds good and, more importantly, I am familiar with it and can get around on it.

It is interesting to read all those threads over on the Motifator forums about people wanting firmware upgrades. We don't buy a keyboard workstation (a sizeable investment worthy of serious consideration prior to purchase in view of what our needs are) for what it might do in the future. Yamaha never promised at the time of purchase that it would do anything other than what it does. Yet, people are demanding firmware upgrades to add this or that feature. It is commendable of a company when they do provide firmware upgrades that add features, but that was not something promised at the time of purchase.

To me, it seems that any of these workstations made within the past 5 years or so (or even further back) are still perfectly fine today. I know people who are still using their Kurzweil K2000 to make fine music. Just watch. After a year or two, when the Kronos has been in circulation for a while, people will become aware of its "shortcomings" and will loudly complain in various forums how this or that doesn't live up to the hype. If the videos still exist from when the Motif XS and the Motif XF were introduced at NAMM or some other similar event, go back and watch them. These sounded REALLY compelling and people HAD to have those workstations too. After the honeymoon is over, people see the keyboard for what it is and start complaining about what it can't do, rather than making use of what it CAN do.

I suspect that most of these workstations, regardless of who made them, can be used to make incredible music. But it is easier to focus on the perceived shortcomings than it is to dig in and really learn to work with the tool and do something worthwhile with it. I would say that the learning/productivity cycle for any of these workstations is far longer than the product lifecycle. There will always be something new just around the corner, and it is the job of the company who makes the product to get us to drool over it and think seriously about throwing what we have overboard to get the next big thing.

From my perspective, that new Motif XF (as does the older XS) has a lot of potential to make some very decent music, and so will the Kronos. Any new keyboard that is being shown and hyped at a show such as NAMM will look like the "best thing since sliced bread". But that excitement will certainly dim when the fervor dies down and reality sets in. This has been true for every workstation made, and I have no reason to believe it will be different for the Kronos. It is also true that, in the hands of a truly creative musician, any of these workstations can make amazing music, and I am likewise sure that will be true of the Kronos.

Tony

Just a thought - for those cases where the FLASH memory is not fast enough to obviate the need for attack caching, why not burn JUST the attacks into expensive high speed FLASH? It might not be suitable for an advanced workstation like the Korg, if it needs to be able to start playback from an arbitrary point in the sample, but it might be suitable for simpler instruments such as DPs. I think we have discussed this type of idea here before.

Greg.

You still need an underlying operating system (and possibly related hardware) that supports streaming... i.e. beginning a sample in RAM (or in flash that is designed to simulate RAM) and completing it by getting the rest out of a storage device (whether hard drive or flash storage device), in real time. Note that even people who are doing this today with their PCs sometimes complain about glitches... it takes a lot of computer power to pull it off well. I'm sure it could be done better with dedicated hardware than on a generic PC, but dedicated hardware tends to be more expensive to design and manufacture too, i.e. if you can't simply use off-the-shelf PC parts.

Are you sure? I don't know the speed specs, but are you talking about the kind of flash used in regular SD cards? I doubt that's fast enough for streaming... SD cards seem much slower than hard drives, and slower hard drives are not fast enough for reliable streaming.


Remember also that on-the-fly decompression adds more processing time, requiring that the media be even faster.


It's easy to put the code for the attacks in RAM, it's easy to put the code for the entire sample on a storage device. The hard part is getting it to work together seamlessly in real time. That's the whole streaming thing I just talked about.


Dewster explained that they get the high speed by running multiple units in parallel. That being the case, saying that the availability of 40 gB for $124 means you should be able to get 4 gB for $12.40 would be like saying that, since a set of 4 tires on my car runs for 40k miles before they wear out, I should be able to drive my car on one tire for 10k miles. The fact that there are, in fact, no 4 gB SSD drives for $12.40, or anything remotely like that, implies that you're talking about technology that does not exist. High speed SSD simply does not exist in cheap, low capacity versions.


As I said, SSD code cannot be executed "in place", it needs to be copied into RAM. Either in its entirety, if you don't have a streaming system, or at least a piece of it, if you do implement a VM streaming system. If you want the code in flash RAM to be executed in place, you're back to having to use much more expensive NOR flash RAM.

Wikipedia isn't the ultimate authority, but a good starting point is http://en.wikipedia.org/wiki/Flash_ram

Are you sure?

Absolutely. (and haven't you seen reports from others here who are doing just this?)

I've just tested my 16GB USB dongle ($50.00 - I was ripped off ;), and it performs wonderfully.
Performing 32Kbyte random reads, the transfer rate is about 18MB/s, which is only slightly less than the SEQUENTIAL transfer rate of 20MB/s. The average i/o response time was 1.6ms.

This is better than my 7200rpm internal 2.5" disk, which only seems to give me about 10MB/s when using Kontakt or EWQLP, despite a high sequential rate of about 70MB/s plus.

Note that it was other PW'ers that opened my eyes to this. Until recently I assumed the same as you.



For simple decompression, where the decompressor only needs to process a few samples before it can start streaming, I doubt whether this would be much of a hurdle.



When I said "code", I was referring to the processor instructions (DSP, general purpose CPU, or whatever). I was not referring to the sample data. I.e - the processor could execute instructions out of very high speed memory, seperate to the sample storage, which does not always need to be so fast.



Yes, understood. However, it may well be possible to source FLASH chips that create a memory bank that has sufficient speed (whilst perhaps not being AS fast), but with a lot less storage. (I don't know though - it just seems plausible)



You might be right, however I am by no means convinced. There is less of a market for such small amounts of storage, however I am not convinced that it would not be possible yet.



"SSD" means a "Solid State Drive". We don't necessarily need a whole drive. I agree that there is the speed vs capacity issue.

I'm curious to know how fast my 16GB dongle would be if it were accessed as directly as possible, without using USB. (anyone?)



Again, I never said to execute code from the SSD. You seem to be confusing code with sample data.

Now, lets look at the performance of my 16GB dongle again.
For 24-bit stereo samples, this 18MB/s of throughput represents a potential polyphony of 68 voices. With simple 2:1 compression, that's 136 voices. Split the samples across two of these devices (trivial in hardware), and that's 272 voices. $100 for 32GB of high polyphony high definition sample memory. Yes, the sample engine will be more complex, due to attack caching.

Will test a 4GB device tomorrow.

Greg.

Understandable wish, and I wholeheartedly agree. It is not a matter of if it will happen, it is a matter of when.

Not all the software pianos with larger sample sets sound great to my ears, so it would still be important to try it. And, we know little about the action (not a Korg strength in the past, IMHO). But, so far, the audio samples of the piano sound amazing.

The one hour video at NAMM shows a demonstration of a "Japanese Grand". I like the idea they included a piano known for bell-like clarity along with a deeper richer piano. And, the samples use 12GB of that 30GB drive, according to the presentation -- this piano could hold an even more extensive set of samples.

For Korg to create an updated next version of this piano, they may only need to add a larger SSD in a few years and more samples -- and they can always just let hardware changes lessen future costs or production and increase power of future releases. What are the economies of scale for Linux? Huge.

Though it seems like a lot of work/pressing against inertia to develop something new in DPs/workstations, by going down this path, Korg may cut their future development time and increase their flexibility. They are using hardware that will enjoy huge economies of scale and massive amounts of research/development in years to come.

Korg can also respond quickly to their customers, because software can be updated rather than waiting for the "next board".

I am using the two interchangeably for brevity. Program code and the data it manipulates are all just ones and zeroes. They are the same to the extent that the parts that are "active" at any given moment must be in space that the processor sees as RAM. Executable code is more often entirely in RAM, but many computer programs do swap out different bits of code during the execution of a program. Data more commonly resides in storage when not in use, but still must be copied into RAM for actual use.

So again, to play that piano note, the "code" for that note (speaking in this case of data, rather than processor instructions) must be in RAM, or in very high speed flash (not SSD) that the processor directly sees as RAM, or it must be accessed via a program and architecture that can support real-time streaming from "storage device" into RAM.

This is the crux of the matter. To use the cheaper flash, you must have that entire streaming infrastructure. I don't think that's trivial. Kronos is the first keyboard to do it. Lots of computers do it, but not cheap ones, and often not very well. So to say that any piano manufacturer should be able to add the function to their pianos for another $5 in manufacturing cost seems like sheer fantasy to me. And if Yamaha, Nord, and Kurzweil could have used the cheap RAM instead of the pricey stuff, I imagine they would have.

Here's a somewhat more comprehensive article:

http://www.eetasia.com/STATIC/PDF/201008/EEOL_2010AUG03_STOR_AN_01.pdf

Parts can be 8 or 16 bits wide. Block size is 128KB. Read buffer size is 2048 bytes (1024 words for 16 bit wide parts). Read buffer load time is 25us, after that each sequential read from the buffer takes 50ns.

Sequential reads for something like a DP sample set would seem to be an ideal thing, as you almost always need the next sample in the series for a particular note that is being played. You would of course have to buffer this in RAM in order to access other unrelated samples in Flash.

For a 16 bit device, reading out the entire read buffer would give ( 1024 / 2 ) / 44100 = 11.6ms of 16 bit 44.1kHz stereo. Reading this would take 25us + ( 50ns * 1024 ) = 76.2us. Assuming full bandwidth utilization of the Flash bus (not all that unreasonable) this is a throughput of 2048B / 76.2us = 26.9MB/s. Comparing real time to access time gives the level of stereo polyphony theoretically supportable: 11.6ms / 76.2us = 152 simultaneous stereo notes (16 bit @ 44.1kHz sample rate).

How much buffer RAM would be needed? I believe each note playing would need 2048 bytes (the size of the Flash read buffer). For 152 notes this is 152 * 2048B = 311KB.

Unless I've made a stupid error somewhere (always possible, and I've never actually designed anything with this interface) I believe I've shown that a single inexpensive 16 bit wide NAND Flash (say 4GB) plus a small amount of buffer RAM could easily support all the polyphony anyone could reasonably want in a DP. Done right it would be one killer DP for very little additional hardware investment.

But as soon as you talk about buffer RAM for streaming data from a storage volume in real time, you're back to talking about implementing a virtual memory system. There's a whole infrastructure required for that in both OS and hardware. I'm not the engineer you are, but as I said, "I don't think that's trivial. Kronos is the first keyboard to do it. Lots of computers do it, but not cheap ones, and often not very well." I just don't believe it's as simple as adding a $10 SD card and loading it up with samples.

There is cheap hardware that streams in real time... an iPod, for example. But the initial seek is not instantaneous. If you've tried to stream a sample library in real time on a cheap PC, you know the hardware isn't up to the task, and most keyboards probably don't have as much processing power as a cheap PC. It's all going to add up to a lot more than $10 in parts, I'd bet.

Anotherscott,
The sample data only needs to be in high speed memory (or processor registers) for the duration of any calculations that need to be performed, before the sample processor sends the result to the DACs. So, it's ok to have a vast amount of relatively slow memory for the sample data, as long as it can be read out of that memory fast enough for the required performance.

Yes, I've already agreed with you that to use slow memory for the sample storage is more complicated, due to the attack caching. I just don't happen to agree with you about the difficulty of doing this, though.

Greg.

Fine, but you're still talking about streaming from "storage" to "live RAM" -- i.e. virtual memory. And an extremely responsive virtual memory system, at that.


I would be more convinced if anyone had done anything remotely like this in a cheap piece of hardware. The closest thing out there might be a V-Machine, and people say that if you're not careful, it chokes all the time. And it probably has more computing power in it than the typical DP.

I don't buy conspiracy theories. If it was this easy, *some* company would have done it to get a leg up on the competition. Korg is finally taking the first step, and it's still a $3k keyboard. And I suspect they were only able to do it because the board is probably linux based like the Oasys was, so a lot of the foundation for VM was already there in the hardware and OS.

No, definitely not that simple. We're just doing back of the envelope calculations here as a initial feasibility study, maxing out interface bandwidths and such. The Flash part itself seems entirely up to the task, and the RAM buffering doesn't strike me as onerous for products in the price range of even low end (non-toy) DPs.


I'm pretty sure I could do a lot or all of this in a $50 FPGA, which is not an inexpensive computing / logic platform. Processors with dedicated RAM and Flash interfaces could almost certainly do it much cheaper. I have no idea what impact there would be on the OS though.

Somewhere I stopped reading this thread; not because I lost it, but because the post became steadily longer and more detailed and dived into the most technical details. Suddenly I remembered the famous words that have too often been repeated , but they just popped up into my mind again; " If it sounds right, it is right !" . In other words - if the Kronos does it's job well and is a real musical instrument that sounds excellent , then why bother if it's SSD, NAND, NOR and 4GB or 13 Terrabite. Let's see what the experiences of the early adopters will be in that respect.

Also I agree with some posters that the amount of GB and technology may help , but are NO guarantee that you have a musical/ well sounding instrument in your hands. Let's wait and see...

Anotherscott,
Please note that I have been referring mostly to simpler products, such as DPs. Not very advanced workstations like the Korg.

Greg.

Thanks! Holy Moses that's frenzied!

Maybe it's the piece, but it sounds too bright and tinkly to me. And that's coming from someone who generally likes bright-ish pianos.

Yeah, it sounds a little bright and percussive for my taste too. Some of the video demo stuff sounded better to me.

There's also a whole second grand piano in there, they talk about a "German" piano and a "Japanese" piano... I don't know whether they are both 4 gig, and if so, which was used for this demo...

EDIT: The Korg site says, "The SGX-1 Premium Piano sound engine offers two distinctive grand pianos; a rich German D piano, and a robust Japanese C model. Each uses superb, un-looped stereo samples sampled at eight velocity levels for each and every key. " So they are probably both 4 gB samples. My guess is that this demo is the Japanese piano, and the one I preferred in the video is the German piano.

.