Piano World Home Page Forums Our Most Popular Forums Digital Pianos - Electronic Pianos - Synths & Keyboards Piano Sampling Question

Anotherscott:
Yes, good idea about using the FLASH for pre-load in the Nord. They could even add a hard disk and use that idea.

Regarding using FLASH chips, I meant that it may be easier to use the same NAND chips that are in SSDs - i.e - the sample engine would be able to communicate more directly with the array of NAND chips. Yes, the interface would need to deal with the paged access. I could well be wrong - maybe Nord looked at that idea and it was all too hard.



What I want to know is that if Korg were to replace that piano with a simple piano that did not contain any damper resonance, what would the new polyphony be? If the answer is still 100, then my theory about the interleaving could be true. On the other hand, the voice limit may be nothing to do with the SSD bandwidth, and could simply be due to the sample engine. (the sample engine may be designed to be able to treat multiple channels for a given sample efficiently)

I wonder why there is a voice discrepancy between the general purpose streaming engine, and the piano engine? Is the 140 voice for HD-1 140 mono voices? Does it halve for stereo? So many questions.

Greg.

I believe that the way the SSD gets so fast is my essentially combining a hard disk controller with an array of NAND chips. The other ways of accessing those chips "more directly" if you will, like thumb drives and SD cards, are slower. But maybe part of that is a USB bottleneck (even though an SSD drive over USB can still be quite fast).


As I said, I believe you can disable the damper resonance samples, and the note polyphony remains at 100.


Each engine has its own polyphony specs. Though each of those specs only applies to each engine running alone. If you are running multiple engines simultaneously, polyphony in each engine can be reduced.


Yes and yes. Though I don't think too many non-piano samples are stereo. Before fx, most sound sources are mono, I think.

FYI, from Korg's web site, here are the polyphony specs:

----


Synthesis Types: 9
SGX-1 Premium Piano (Acoustic Piano)
EP-1 MDS Electric Piano (Electric Piano)
HD-1 High Definition Synthesizer (PCM Virtual Memory Technology)
AL-1 Analog Synthesizer (Analog Modeling)
CX-3 Tonewheel Organ (Tonewheel Organ Modeling)
STR-1 Plucked String (Physical Modeling)
MOD-7 Waveshaping VPM Synthesizer (VPM Synthesis)
MS-20EX (CMT Analog Modeling)
PolysixEX (CMT Analog Modeling)

Maximum Polyphony*1*2:

SGX-1: 100 voices*3
EP-1: 104 voices
HD-1: 140 voices
AL-1: 80 voices
CX-3: 200 voices
STR-1: 40 voices
MOD-7: 52 voices
MS-20EX: 40 voices
PolysixEX: 180 voices

*A portion of the multicore processor in KRONOS is devoted to generating voices, and a separate portion is devoted to generating effects. KRONOS dynamically allocates the voice processing power between the engines as necessary. The quoted maximum numbers of voices apply when 100% of the voice processing power is devoted to a single engine.
*2 In rare cases, when a large number of processor-intensive effects are active simultaneously (for instance, more than 14 O-Verbs), polyphony may be slightly reduced.
*3 100 dual-stereo notes (It corresponds to 400 voices in the maximum.)

We'd have our own custom interface into those FLASH chips though, optimised for sample playback. It may be BETTER than those hard disk controllers, because it will be designed to perform one function only - sample playback.



Yes, I understood that the first time you said it, but if the damper resonance sample data is stored interleaved with the normal pedal-up sample data, it will almost certainly still read the resonance sample data as it streams, but then just throw it away. Remember, the SSD is read in pages at a time - not just individual samples at a time. So, IF the bottleneck is the SSD, simply turning off the damper resonance function won't achieve anything. Hence my interest in knowing the polyphony of an instrument without any damper resonance. I'm sorry I didn't make myself clearer at the outset.

Thanks for the other info. (still hard to figure out exactly what's going on inside though.)

Greg.

here you go..(apologies, peterws - we're drifting into outer space..)

AHCI disabled





AHCI enabled



- so, yes, AHCI definitely an improvement and markedly so for the QD32 figures. Unfortunately nothing like as good as the published benchmark you linked me to although I'm delighted with the drive, my most satisfying upgrade ever!

Thanks! Btw, I didn't know SSDs had come down so much in price. Great stuff.

Greg.

This flash/ssd stuff will become even more confusing in a couple of weeks and more so by the end of the year ...... hardware is going to change a lot over the next 5 years. More then it has in the preceding 15 years.

Don't forget how this particular thread of our discussion started. It started with you saying this:



I.e - you seemed to be saying that it is IMPOSSIBLE to do away with RAM, even if the system worked extremely slowly. All I have been trying to prove to you that it is most certainly ENTIRELY possible for a CPU to operate with our RAM.

Now, again, going by the specifications of today's SSDs, it seems to be that it may be within the realms of possibility to stream samples directly from SSDs. That's all I'm saying. This is VERY different to saying that we could build a world class supercomputer using only SSDs and no RAM. We have a very specific application, and that's all I'm referring to - that application. And btw, yes, the sample engine probably will need some RAM - and I said that before. It won't need as much though - enough for the instructions and temporary storage for the calculations it has to perform. Obviously I'm talking about a real system now, that performs as a sampler and produces audio in real time. We could actually design it without any RAM at all, and use the SSD for everything - instructions, temporary storage, and sample data. We'd need to design a special controller to allow this, but it would do all the same things - except - far too slowly. It would not be able to produce data at a high enough rate to be used as audio in real time. It would be a very strange contraption, but it would still slowly produce the same audio stream. This audio could be stored, and then played back later, and it would sound identical to the real system that was designed properly. (and of course, it would need to be fed with a pre-created MIDI file, or if live, a MIDI file that was being drip-fed into it in a very controlled fashion)

Greg.

There've been some big price drops.

In the uk I keep a watchful eye on http://www.hotukdeals.com/ where various fanatics are happy to signal deals when they turn up. I'd imagine you've something similar?

Regarding this thing about needing or not needing RAM in the hypothetical, SSD-based piano ...

Does it even matter? RAM is so cheap these days ... the amount needed in such a piano would cost next to nothing. Eliminating all RAM would not cut much cost, would it?

And anyway, the piano would need at least some RAM for ordinary program data storage. You wouldn't want to push program data onto the SSD-acting-as-RAM, would you? We'd want the SSD to be read-only to preserve its life-span.

So the whole RAM thing is moot, eh?

MacMacMac: Yes - I agree - it would need some RAM, and I said that before. I certainly haven't been trying to say that the sampler should completely do away with RAM. All I've been saying is that we might be able to retrieve the sample data from SSDs without any pre-load buffer, which is a very different thing.

I don't know whether you saw my previous reply, but I said that we could, in theory, actually push everything onto SSD, but I completely agree, we wouldn't want to - it would be terrible. The point is - the system would still do all the same calculations, which is contrary to anotherscott's assertion:


(in this case the "hard drive" is the SSD, but same concept)

Anotherscott: You do understand that the sample engine will still be reading it's instructions from RAM of some description, yes? This memory does indeed have to be "normal", high speed RAM, in order for the sampler to function in real time.

Greg.

(and the "whole RAM thing" may be moot, but the elimination of the pre-load buffer is NOT moot, IMHO, for the reasons I gave earlier)

Also, if we're using a dedicated hardware sampler (as opposed to a general purpose computer), only a very tiny bit of RAM might be required - some high speed SRAM that actually resides inside the sampler chip, for example. The instructions would be micro-coded in to the chip, and the SRAM would be required for the buffering of the pages of SSD sample data and for general processing/effects.

Greg.

Correct, that is my understanding... that there needs to be RAM, or some other component that the processor sees as equivalent to RAM (i.e. NOR flash, but not NAND flash which isn't random access). Maybe I'm wrong, but this is my understanding, at least with current technology.


But you're doing that by postulating some controller that, AFAIK, does not exist. You may want to design and patent it. ;-) Though the need to be able to have a processor operate with an SSD but no RAM may be limited, unless maybe this theoretical controller is cheaper than the RAM it is replacing.


That makes more sense to me.


But here you're back to the part that sounds suspect to me (even with your caveat that it would be slow), unless you know of (or can design) such a controller. A lot of things can theoretically exist, until an engineer actually tries to make one. ;-)

I really think it would be quite easy. However, this controller would admittedly need a small amount of memory - not necessarily RAM, but some kind of a buffer, to store at least the minimum block size of the FLASH that can be written to in one go after a block had been erased. The reason for this is that if the CPU attempted to write to a location in FLASH that was not blank, the whole block associated with that area has to be erased and then written to in one go. This is one reason this system would be very slow, because this would be happening all the time.

Just by the way, I've thought of something that many general purpose computers do, that comes very close to your example of the CPU of using a hard disk. When the CPU attempts to access an address in RAM that has been paged out to disk, the memory controller prevents that access from completing until that page of memory has been read from disk and written back to RAM. (in reality, my understanding is that the CPU is actually involved in transferring that data from disk to RAM, but a system could probably be designed where the memory controller does all that work) That's why it's called "virtual memory", because the CPU is now generating "virtual" addresses - addresses that don't correspond with addresses of the physical RAM - these virtual addresses, instead of being sent directly to the RAM, are sent to a middle man - the memory controller.

If you still doubt me, maybe you could ask a suitably qualified engineer that you trust and respect. If they disagree with me, they're incompetent - find someone else. ;^) ;^)

Greg.

But that also reinforces my perspective, in that the memory controller does not feed the data from disk directly to the CPU, but rather transfers it to traditional RAM where the CPU can they have its way with it. Cutting out the RAM "middle man" is what I have not seen in any actual implementation.

I never said we should design a system that way. You said it would be impossible, even if the system operated very slowly.
I maintain that it is possible, but I agree - it would be very slow!

Now, with the virtual memory, I said that it "comes very close". I didn't say it was exactly like your example.
To make it exactly like your example, the system would be designed to indeed transfer the data directly from the disk to the CPU. It would be outrageously slow, but it could be done. Should we do it? Of course not, and that's why it probably has never been done!

EDIT: Here we go!
Texas Instruments: Booting DaVinci EVM From NAND Flash

Quoting:


That "FLASH translation layer" they refer to would do precisely what I described before. (although it seems they are somehow using software for that - I haven't read the whole document)

Greg.

Nothing to add. When I play digitals, it's always DP. But recently I recorded with some piano sampled in VST. I don't know which one (sound man loaded it), but I was amazed that it can sound like the grand, at last in terms of timbre and color! You really hear grand piano, not like in most (if not all) DPs.

I guess for decent recordings, you don`t need a terrific DP, just a good piece o` software piano? (And a reasonable keyboard)