Piano World Home Page Forums Our Most Popular Forums Digital Pianos - Electronic Pianos - Synths & Keyboards Why big brands still stick on short looped samples in 2020?

I think that's really the key. Personally, I feel these things are cyclical. Today, virtually nobody talks about looping, and hw DP sounds are considered competitive and in some ways even superior to VSTs. And they still have few velocity layers and looping. They've definitely gotten better than from a decade ago, but my guess is we'll swing around in a few years to DPBSD-level hate of hardware sounds, no doubt shepherded by some influential opinions here...

Programmed obsolescence.

And we are guilty of funding them by compulsively buying the latest and greatest as soon as the manufacturers even just announce them (thinking about pre-sales here)

Sad but true

Shouldn't we be talking about pivot lengths right now?!

That's correct. And, please, don't forget music rest widths and fasttrillsability!

I don't see many people on this forum saying that current DP piano engines gives you a better piano sound than what you would get from the best piano VSTs... But I see some people here using VSTs with hybrid DPs (which supposedly have top-range piano engines).

So, do you think today DP piano sound quality is at the same level or even better than the sound quality of the best VST?

I still have a CLP-150 from 2003... Perhaps I am not the only one to keep something working such a long time.

But I plan to change it by a N1X...

I plan to keep it ever longer (I don’t think the action will get better, and if the sound doesn’t please me, VST are my friends).

Mine is currently 47 and three quarters of a British Inch; ie a tad under 4 feet. It also has not two, not three, but FOUR music restraints! Or will have tomorrow if it's not raining, whereupon I might complete it.
Anybody beat that? And does size really matter?

That's a different kind of memory.

Typically, a keyboard cannot play samples directly from low-cost (NAND) flash. The data usually must be copied into real RAM first, so you have to add the cost of the RAM (and also allow for a longer boot time as the data is copied from flash into RAM, which I believe is what the Dexibells and some Korgs do). Alternatively, NOR flash can be used, which solves those problems, but is more expensive (it's what Nord uses). There are some exceptions, some boards that can play samples without having them in RAM (or NOR flash, which acts like persistent RAM). Korg Kronos can stream from SSD, because it includes an entire Linux computer. It works well, but it is somewhat pricey and takes a long time to boot. Kurzweil has their patented flashplay, I'm not sure what they're doing.

Reading speed is not the only issue. Besides what I mentioned above, try running a VST streaming piano with all the sample data on that SD card... I suspect that your results will be disappointing.

I did this ... and it worked fine.Kontakt will buffer a specified amount of samples in RAM, so there's some load time. But big, good-sounding samples with a bit of load time beats small, crappy instant-on samples.

I'm glad to hear it worked! In terms of being able to stream sample data from the SD card, I guess the question is, how much RAM did you have to dedicate to sample pre-loads? Does Kontakt allow you to change that amount based on your system? Specifically, do you have to give it more RAM to work with if accessing samples from an SD card vs. accessing them from an internal SSD, or does the pre-load remain a constant?

Still, I think the pre-loads are key... no matter the speed of the SD card, even a full computer can't play the entirety of the sounds directly from the SD card in real time. So I guess even more pre-load is required if you want to be able to, for example, switch from piano to Rhodes to Wurli, etc. But Kontakt is something I've never used at all.

You can change the default per-note buffer size. But I did not change it.

With the default buffer settings Vintage D loads 252 MB of RAM. Other pianos load a similar amount.

@anotherscott: if an sdcard is not fast enough for random access reads, then there is always the SSD option.

SSD 120GB: ~20 euros.

Considering the speed of an SSD, even for random access reads, I think you don't need to copy first all the samples in ram. In the worst case you can do what Kontakt does: it copies in ram just a few seconds of each sample... This was absolutely necessary with mechanic hdd, but I don't know if it is still necessary with SSD technology.

As I mentioned, it's not merely a matter of speed. The key point is that not all kinds of memory are functionally interchangeable.

Processors cannot play samples directly from (NAND) flash nor from SSD. The samples must be brought into RAM first. Which means not just adding the cost of the RAM to your SSD cost, but if you want to pre-load just bits of sounds instead of the entire sounds (getting the rest on an as-needed basis, as with the Kontakt example), there also needs to be a hardware and software (OS) infrastructure system that supports that low level virtual memory management to swap the data in and out of RAM on the fly. And that's exactly how the Korg Kronos works. But for that to work, Korg needed, not just an SSD (which indeed it has), but also a full Intel PC motherboard running linux. And while you can put as large an SSD as you want in it, you will still be limited in available sounds by the amount of RAM available to pre-load what must be instantly available. (So to answer your other question, yes, even with SSD, some of the sample must be in RAM... and regardless of whether it's a few seconds or much less than that, ultimately, *every* waveform must travel through RAM before it can be played, whether it's pre-loaded or subsequently fetched.)

Now admittedly, Kronos came out 9 years ago, maybe something different could be done now, but certain basic principles have not changed. With the possible exception of Kurzweil's patented flashplay, AFAIK, DPs/keyboards can only play sound out of either custom ROM, NOR flash, or RAM into which some or all of the data has been loaded post-startup... all of which is pricier than SSD or the NAND flash that is used in USB sticks and the like. You could not pop out the ROM/NORflash/RAM of a keyboard, put in a larger-capacity-but-cheaper alternate type of "memory" like SSD or NAND (which is better thought of as "storage" than "memory"), and have the keyboard simply function as it does now except with larger sample sets. Just as you could not run your PC with no RAM and simply use its SSD alone. Even if you were willing to live with it being much slower if that were the tradeoff, it simply would not work, because RAM and SSD--though both often called "memory"--are not functionally interchangeable. It's not just a matter of speed, it's that they are completely different kinds of things with different functionalities. That's not intutively obvious because people use the same word ("memory") to describe these different things, and these different things are measured the same way (in megabytes, gigabytes, etc.). But that doesn't mean they all do the same things except at different speeds... that's not the case, the differences go deeper than that.

I'm not sure if I have gotten this right, it's more of an educated guess than a concrete thought. How does the S3 sleep on a PC work? It works by holding stuff on the RAM as long as there is current. So if I turn on my PC and put it on sleep, the next time is will resume quickly and won't reload all the heavy OS stuff...
Now, a DP is far lighter on resources than a full fledged PC and I suppose something akin to the S3 sleep could be done at least on the paper, since it's a chipset feature built into motherboards and SoC.

All I'm saying is that, with a few gigabytes of nonlooped samples on a NAND flash drive and a few gigabytes of RAM and a custom firmware, it should be possible to achieve the goal, albeit perhaps with an increased net price.

1. It's not a majority opinion, but there are several folks on the N1X thread that praise the realism of the CFX binaural sample patch, and prefer it over VSTs. This isn't something you'd hear at all here 5 years ago, so even if it's a minority position, it's still a notable trend.

2. There are definitely people who use VSTs with hybrids (I'm one of them). For most people, VSTs are still the gold standard, and the people who can invest in the best action available probably also consider the best tone possible.

3. Personally, I'm not in that camp, I think Garritan CFX is tonally superior to the built-in sound of my DP. But CFX's sympathetic resonance engine is very primitive and muted compared to Kawai's SK-EX Rendering, and I imagine it's the same against the latest generation of VRM....so the HW DPs are not resting on their laurels on all fronts.

@anotherscott: I don't know why, but you totally misunderstood what I said. I never said to remove RAM from a DP (that would be very stupid). I never said to use an SSD as a replacement for RAM, but just as an alternative to store the samples (i.e.: a cheap alternative to FlashROM and similar things most DPs currently use to store the samples).

A Linux OS can work very well on a multitude of Intel and not-Intel hardware. We have Linux on smartphones, router, security cameras, videorecorders, smart-TV, Raspberry Pi, etc., so I guess there is nothing wrong in building a DP powered by a Linux kernel, as the Korg Kronos already does.

OK, so put in some flash AND some RAM.
For my part, I don't care about RAMs and ROMs and SSDs ... I just want better samples.
Put magic in there if it'll help.
Put some rats on treadmills in there, too.
Just make it so!

I didn’t know about Kurzweil's patented flashplay, but Yamaha has a DSP (SWP70) which can read directly samples from a NAND memory via an ONFI bus. (It has however a little RAM work area).

Then unlooped samples may be possible with Yamaha technology.

(I read « Kurzweil is proud to announce our patented new technology, Flash Play� !
It allows us to play many GBs of samples with extremely low latency and zero loading time. »)

I think you missed MY point. ;-) I was not talking about removing RAM from DPs... most DPs do not have much if any RAM in the first place, so there's nothing to remove!

There are three typical (non-computer) scenarios, as I understand them:

1. Most often, the piano samples are stored in ROM, which is directly usable. These boards do not use RAM (except maybe a small amount for user settings and such.)

2. Nord (and to a lesser extent, some other boards) use NOR flash, which is essentialy rewritable ROM (which, I know, sounds like a contradiction) which, likewise, is directly usable. It's advantage over ROM is that the contents can be changed, so you can update the piano sample set. But it is a more expensive way to go. Again, these boards don't use RAM (except maybe for settings, etc.).

3. AFAIK, Dexibell and some Korgs are the only ones that store their samples in a non-directly usable media and load their samples into RAM in order to make them usable, so yes, those boards play their samples out of RAM, but most do not. (Copying their data into RAM contributes to the longer startup times these boards may have.)

For scenarios 1 and 2, you cannot directly just replace the ROM (or NOR flash) with a larger SD card or an SSD, because, regardless of speed, samples on these media are not directly playable. You'd have to *also* have RAM. So you either have to add enough RAM to hold the entire sample set (which is, in essence, scenario 3... and essentially more than negates any "savings" from using an even larger SSD because you have to match the SSD with the additional cost of a comparable amount of RAM), or if your intent is to include only enough RAM to pre-load the beginnings of notes (to permit much larger sample sets), you're back to also needing some kind of hardware/software infrastructure to deal with the real-time data swapping, which so far has not been done without the resources of a full computer (i.e. Kronos).

Yes, linux can be implemented on pretty minimal hardware, but that doesn't mean that an implementation on minimal hardware would be able to do the kind of real-time data swapping in and out of memory needed for the task at hand. I would imagine that if a Raspberry pi were sufficient to do what a Kronos does, Korg would use that in the Kronos instead of the PC motherboard it uses, and save themselves a whole lot of money!

That's what Korg did with the Kronos... they put in flash (SSD), RAM, and everything else it needs to "make it so." It has a selection of multiple multi-gigabyte pianos you can instantly switch among, AND you can load your own soundfonts so you can get other pianos into it as well. So I guess you just want more companies to do it. Which is understandable... you may prefer someone else's actions, sounds, features.

Yes, Yamaha is also doing something interesting there, I forgot about that! They have used Linux for quite some time (I believe going back to the Motif XS), but they do not use it on standard PC hardware the way Korg does in the Kronos, and it was not originally capable of any kind of "streaming" nor playing off of NAND, but they did come up with their own propritery (and patented) hardware approach, described at http://sandsoftwaresound.net/swp70-tone-generator/ - which is really interesting reading if you want to begin to understand the complexities of accessing samples off of storage in real-time, further explaining perhaps why you can't just pop out the ROM of a DP and put in an SSD instead.

That's an interesting question. As pointed out, if they could play right off NAND, well, a lot of NAND can be included at minimal cost these days. But without fully understanding this patented tech of theirs that allows it to work at all, I would not venture to guess as to what its maximum capacities might be and/or whether there may be other bottlenecks that could need to be addressed in order to deal with much larger sample sets.

That's nice to know. A DSP with direct access to a NAND memory means a more efficient design (no need for transfers from storage memory to RAM and then to the internal cache/registers of the CPU/DSP).