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

Love readin` all this; I`ve forgot what me question was! Ha ha

That's a pretty big statement, but I do think it can do that. I've just tested a 30-note chord, with an instrument that consists of a single sample of a narrow click (an impulse). Playing it back in real time in my DAW, it sounds exactly the same as it does when I play one of the sample files - I hear just a single click.
Now, when I introduce a 1ms skew between each Note-On, I hear a short 1kHz beep instead. ;^)

It doesn't work as well when I use a MIDI player with a virtual loopback cable though. With no skew, the click sounds fuzzy, and with the skew, it sounds very farty - nothing like a 1kHz beep. I'm curious to see what a physical USB MIDI connection would sound like.

Greg.

- thread drift...dontcha just love it!!

It is streaming piano samples, as shipped, as well as with any alternate piano you may install on it. But my understanding is that you can only trigger a single VST instrument on it, so it is effectively limited to being just a piano. AFAIK, there is no mechanism for loading multiple VSTs, splitting/layering of sounds, etc.


Yes, it streams from the SSD, and pre-loads the beginnings of the samples.


I suspect that pre-load is always useful, because data cannot be executed directly from SSD, it always has to be read into RAM first. So having some small portion already in RAM gives it something to play while it goes out and gets the rest. So having designed the rest of the streaming system, I don't know that trying to do away with the pre-load would make things any simpler, it just might make things more complicated! It seems to me that the pre-load is a pretty nice solution to possible problems, even if it were conceivable to implement a streaming system without it (and I don't know whether that's possible or not).


I don't think that being "co-located" is any issue at all here. A single pressed key can generate 4 samples... left, right, damper resonance left, damper resonance right. So 100 note polyphony can be 400 sample polyphony.


Pre-load of the start portion of a sample would pre-load that information into RAM, not fast flash.

Minimal forms of linux are used for various embedded applications... GPS devices would be another example. But I don't think the hardware or OS implementation in these devices is capable of the demands of a DP application, even if you put more/faster storage in them. I don't think the router example or GPS or whatever actually negate my paragraph that you quoted. Put differently, I doubt the Kronos (which people have taken to task for perhaps too much cost cutting) would have essentially a full computer motherboard inside (even apart from the RAM and SSD) if they could have done the same thing with the electronics from a $30 router.


Some are... Yamaha started doing that in the Motif line starting with the XS, I believe. I would not be surprised to see the next generation of Motif supporting streaming.

Except that, in order to run it, you need to already own a substantial dollar investment in hardware that they are not supplying. And it is still not as operationally fluid and "bullet proof" as what we expect in a dedicated instrument, essentially because they are using a commodity rather than a task-specific platform in order to keep the costs low.


Keybeds are expensive to tool up for and to manufacture (even if you have the appropriate design expertise, which is a whole other question), which is why only the biggest manufacturers make their own, and all the smaller ones buy them from Fatar or other companies. Outside of large volume and significant in-house engineering resources, it is cheaper to buy a keybed as an OEM piece than to make your own, but the mechanism and the electronics are still not dirt cheap.

Well said Scott! (x3)

I thought it came with Pianoteq, which of course doesn't stream.



Thanks for the info - much appreciated.



Data is not executed - instructions are executed. Data is processed. I think you are making too much of this "pre-load" business. The ONLY reason to pre-load is if the mass storage used for the samples has too much latency. If that is not the case, when a player plays a note, there is no need whatsoever to store the beginning of the note in a different area of memory - it can be read directly from the mass storage, and then processed by the sample engine. (and yes, the sample engine will have it's own small amount of high speed memory, but that's not a big deal).



If the pre-load could be eliminated from the mass storage, it would possibly allow functionality which isn't currently possible - for example, to vary the attack start point of the sample during playing. With the pre-load, there would not be time to do that.



It is a very big issue IF there is no pre-load, which is what I was assuming, because in order to maintain a given latency, the number of areas that have to be read from simultaneously is critical. With a pre-load, the pre-load buffer allows a very good latency, and given that the SSD has such an enormous throughput, I agree - I don't think it would be a problem to support a completely independent 400 voices. I maintain though that if it really did support a truly independent 400 voices, why didn't they just say that?



It would not have to pre-load into RAM, but if you're saying that's how it is, then ok. If the attacks resided in high speed non-volatile memory, there would be no need to pre-load at all.

EDIT: In summary, I guess what I'm saying is that it may be possible to design an SSD interface for the sample engine that makes the SSD look like RAM. Yes - maybe you're right that this is more complicated than simply having the pre-load, but if the SSD is fast enough, I think it would be worthwile. Instrument load times would be further improved (I suspect it's already good though), and it may allow other functionality, because it would allow random access into the sample in a way that isn't possible when using a pre-load buffer.

Greg.

Sorry, my mistake! I forgot Pianoteq is not a streamer. ;-)


Sorry for the imprecise shorthand, but I think you get the idea. The instructions are executed upon the data (what you are calling "processing"). The point is that the data on the storage device somehow needs to be brought into memory on its way to being converted into "music."


I'm not really following this. AFAIK, since an SSD has no moving parts, there is no difference between a note's data being "close to" or "far from" another's.


High speed non-volatile flash memory that can function as traditional RAM probably doesn't make sense in a streaming system, since that kind of flash is expensive and enormously slow to write (it's what Nord uses for the entire piano sample, and what Yamaha uses for optional loadable sounds into their flash memory cards in the Motif XF.) If you have a streaming system to start with, you might as well just use RAM for the pre-load, as it is cheaper and its contents can be changed more easily and quickly. I don't think there would be any advantage to using flash for this.

The point I'm trying to make is that it appears to me that the SSD, just maybe, is already fast enough to be considered as high speed memory, for the purposes of sample playback. Yes, it needs an interface to the sample engine - but so does standard DRAM!



It does still make some difference, because we still talk to the SSD in "transactions", and it has a finite rate at which it can do this. As I said, the specified rate is about 100K for today's fast SSDs, but it seems that the achievable rate is about ten times less in a real system - at least - a real general purpose computer. So, we can't jump around to different areas of the SSD anywhere near as fast as we can with RAM. I've asked in a storage forum about the feasibility of achieving 100K transactions/s.



It would reduce instrument load times, because there would be NO pre-load at all. (and the write time would be irrelevant, because that would only be done once, when the instrument is installed)

Just btw, does the Kronos load all it's non-streaming instruments into RAM when it boots? If so, I wonder how long that takes.

Greg.

My understanding is that SSD is based on NAND flash, which a processor can only access as storage and not as memory, and that has nothing to do with how fast or slow it is.


SSD does have a finite rate, but the speed with which it can, for example, play a B note after a G note has (AFAIK) nothing at all to do with how "close" or "far" the data for these notes are within the SSD.


Only to the extent that you use the same instrument every time you turn the unit on. Considering the extra expense (I believe about ten times the cost of RAM), and the fact that changing what you want the contents of the pre-load to be requires enormous write times, I think it would be an unlikely design choice.


Typically in the range of 2 to 2 1/2 minutes, which loads all the non-streaming instruments as well as the pre-loads for the streaming instruments. This can vary by changing what you want pre-loaded.

To get back the previous paragraph, if they used high speed NOR flash instead of RAM, it would load much more quickly. (I would guess maybe in the range of 15 seconds.) But if you wanted to load a completely different set of sounds that you had set up, instead of taking, again, 2 to 2 1/2 minutes to re-boot with an alternate pre-load, it could take over an hour to put the new pre-load into, say, 2 gb of flash. And it would probably raise the price of the Kronos perhaps by about $500, besides.

Though it would be kind of cool to be able to specify a certain user-definable "ever present" sound set that would boot quickly from flash, while also having available RAM for loading additional sounds within some reasonable amount of time without the long "burn" time it takes to put them into flash.

I don't know how the Kronos is designed at the moment, but the point I'm making is that the SSD (going by the specs - I don't care how the SSD is designed internally) is arguably fast enough to be considered as "random access memory", for the purposes of sample playback. It's just design detail as to how to implement a system that can use the SSD like this, without a pre-load. For example, if an ASIC is being used to play samples, it would need to be designed to able to talk to the SSD, but it's exactly the same situation with DRAM - that ASIC would need to be designed to be able to read from DRAM.
The SSD interface may well need to have a few hundred kilobytes (or maybe a few megabytes) of buffer memory in order to efficiently transfer the data from the SSD, but that's a trivial design detail.

Now, if the Kronos uses a general purpose CPU, then we know that the necessary interface chips are already available for both DRAM and SSD, and no extra work is required. Yes - some RAM would still be required for this general purpose CPU when using the SSD without a pre-load - of course.



That is simply incorrect. If we use a real-world access time for an SSD of 0.1ms, then the absolute minimum time delay between the two notes, assuming that each note is played immediately by the sampler when it receives the Note-On, is 0.1ms. For 100 voices, there'll be 100 x 0.1ms = 10ms of time delay between the first and last notes. You may argue that these are such small values as to be negligible, but I think it's important to be aware of it. Remember - I have been trying to design a Rolls-Royce system where it is able to sound all notes simultaneously, at least to the resolution of an audio-buffer's worth of time. If it is only possible to achieve a latency of 0.1ms, then my design is impossible without a pre-load buffer, for a polyphony of 100 voices. (I take Dewster's point that I'm probably over-engineering, though)

Now, regarding storing the attacks in high speed FLASH, remember that we only need a relatively small amount, because the pre-load is a tiny fraction of the total sample storage. (especially so when streaming from SSD!)

2.5 minutes is a long time. It'd be interesting to know how much of that is just plain old operating system boot-up time. ;^)

Greg.

I think I understand where you're going. Though I think it's a long way to go for the benefit of being able to play a sample from some point other than the start... which I think could currently be addressed with just a second set of pre-load data (and even then, possibly only if the alternate start is, itself, not contained within the first set of pre-load data). Though if you want a myriad of different possible start points, i.e. any point along the sample, then yeah, a system like what you describe would do that. I'm not sure of the need for that though!

Anyway, just to be clear (and I think you know this), it's not the case that a computer could operate with a hard drive but no RAM at all if it weren't for the fact that the hard drive is not fast enough. Even if a hard drive (or in this case, SSD) was fully as fast as RAM, the processor "sees" them differently, and the NAND flash used in SSD is seen as storage and not as memory, so the data still needs to come off the storage mechanism (SSD) into RAM on its way to generating the sound.

(And this old link might help a bit: http://en.wikipedia.org/wiki/Flash_memory#Distinction_between_NOR_and_NAND_flash )

But yes, the faster the storage device, the less RAM should be needed for pre-load... and perhaps there is a point where the pre-load can be eliminated completely, and I guess that's really where you're going.


I'm afraid you've lost me on this one... I don't see how that response relates to the part of my post you quoted. Maybe I didn't understand what you meant about the data for voices being "co-located" which is at the core of this question. But basically, what I was saying is that, as access time on a non-moving device is effectively zero, the actual location of any data on the device is irrelevant. (Except to the extent that only certain kind of access can be done at all, and then we're back to NAND vs. NOR.)

It's more than just being able to do that. It reduces instrument load time as well, and it removes the "process" of pre-loading, which may simplify the system design. I.e - the fact that the attacks no longer have to be treated any differently to the rest of the sample may ease the system design a bit. I don't necessarily think it's "a long way to go", either. I think it is a long way for YOU to go, because it seems so foreign to you. ;^) The East West Play documentation mentions that it has now been optimised for SSDs, which reduces instrument load time. There's a bit of real-world evidence for you that it's a worthwile thing to do - even when using SSDs.
(it's a bit vague on detail - I think it does still use a pre-load, but a much smaller pre-load. The way it is worded suggests that it may actually use no pre-load for a certain percentage of samples in any given instrument though, which would be interesting)
EDIT: Well, that's not really evidence that they feel it worthwile to try to eliminate the pre-load completely. However, I don't see why they wouldn't completely eliminate it if they could.



It most certainly IS the case. All that matters is that the data be able to be loaded into the CPU, so that it can operate on that data. I completely disagree with that statement.



Again - I completely disagree! The SSD, whether it uses NAND FLASH, NOR, or magnetic core memory from 70s, can look EXACTLY like memory to the CPU. All that is needed is the right interface hardware. The CPU generates the address that it wants to read to or write to, and then the interface translates that address into some action on the storage.



Precisely.



Taking the example of playing two notes together, and assuming the SSD has an access time of 0.1ms, can you not see that the minimum time between the two notes must be 0.1ms? Remember - the access time is the time taken for the SSD to switch from reading data from one area, to reading data from another area. Obviously, the sample data for these two notes will reside in seperate locations on the SSD. The sampler reads each sample sequentially, and in little blocks, switching rapidly between the two samples as it proceeds through the two-note chord. Each time it switches, it takes 0.1ms.

Now, for the simple case of a stereo sample, we'll still only have one "sample" file - one stream of data. The two channels will be stored in an interleaved fashion in this sample file, so that as the sample is played, we will always be reading from the same area of the SSD, assuming that the sample is not fragmented. We will be reading sequentially through that sample, and in this case, the access time is irrelevant (except for the Note-On latency, which will be at leasts 0.1ms. We will need to buffer the data from the SSD to ensure seamless playback, too - that's where it differs to DRAM) - what matters here is the sequential transfer rate (which is absolutely huge - hundreds of megabytes per second).

Taking this further, I'm suggesting that what Korg might be saying is that it may store, for example, multiple mic perspectives for a piano interleaved in each sample file, and this is how they get the inflated voice count of 400 - it's still reading from 100 physical sample files, but each sample file consists of 4 channels of audio. (two stereo channels, or four mono channels, etc. They seem to be saying that one voice is "dual stereo", so perhaps it's really 8 mono channels?)
If this is true, the transaction rate is 4 times less than it would be if each mic perspective were stored in seperate sample files, because each transaction would read a gob of data from all 4 channels.

Greg.

RE: the 100K transactions/s, I suddenly remembered about command queuing!

Look at this result for the Samsung 840 (NON Pro):
http://www.legitreviews.com/article/2077/5/

The two lines of interest are the ones that use an io size of 4k - they are for random 4k ios, the first without queuing, and the second with command queuing with a queue depth of 32.
See how much higher the throughput is with queuing?

Doing the maths, the access time for non-queuing is what we expect - about 0.1ms (~10,000 transactions/s) With queuing, the transaction rate is about 95000/s, which meets the published spec.

Dire Tonic: see if you can somehow run a benchmark with command queuing. Hopefully your disk controller will support it.....

I don't think a sampler can rely on command queuing, although it would sometimes be able to use it if it wanted to.

Greg.

I guess it would be a matter of how much effort it is to eliminate it (since it already exists in current designs), and what the benefit would be. Reducing the amount of pre-load is probably an easy change to make, in that the basic architecture of the system remains the same... as you've been suggesting, I think you're correct that, the faster the media, the more they can reduce the pre-load, and there would be a benefit in smaller RAM consumption and less time required for the initial pre-load itself. Though, assuming it is even possible, I would think that eliminating the pre-load completely from systems that currently depend on it might require a bit more re-design in the underlying architecture of the system.

Back to the SSD-based Kronos as an example, pre-load can be pretty small in its current architecture. Someone came out with a large set of Rhodes samples, the samples take about 875 mb on the SSD, but the amount or RAM needed for pre-load is only 37 mb (so, down around 4%). Now, what would be needed to eliminate even that 37 mb pre-load? Would a faster SSD do it? Faster processor? Different code? Some combination of these things? And on the flip side, how significant is the benefit?


This is not my understanding. What about the issue of "random access" versus "page access" as referenced on that NOR/NAND wiki page I referenced?


Yes, but as I understand it, that .1ms would be the same regardless of whether the data on the SSD for the second note is directly adjacent to the first note, or at some "distant" location many blocks away, because unlike a hard drive, physical access is not an issue. So I am uncertain, are we in agreement about that or not?


Your description of what Korg is doing sounds far more complicated than what it is. They support 100 notes of polyphony on the piano. Since each note can contain 4 samples (left and right note, left and right damper resonance), that's up to 400 voice polyphony on up to 100 notes. You can read this in the words of Korg's Rich Formidoni at
http://www.korgforums.com/forum/php...amp;sid=54aa33582dfd967bf2118aa5292440dd
Multiple mic perspectives and such have nothing to do with it.

I disabled AHCI a while ago (I can't even remember why!) but will reinstate it and give it a try with the benchmarker, probably tomorrow...

I'm not suggesting that Korg bend over backwards to elimininate the pre-load. All I'm saying is that it's starting to look like it might be possible. (although now that I understand a bit more about the SSD specs, I'm not quite as keen, although it might be easier using FLASH chips rather than an SSD per se)



That's very simple. The storage controller that would interface the CPU to the FLASH device would handle that detail. As the CPU jumps around, feeding the controller random addresses, the controller would do whatever it needed to, to fetch the data corresponding to that address. If the FLASH can only be accessed in pages, the controller would know how to translate an address from the CPU into the correct commands to request the page of data from the FLASH that contained the data at the corresponding address. It could either then throw away all data EXCEPT the data for that one address, or it could cache that page, in case the CPU requested another address from that page. It's just design detail.




Agreed. The point is - it still takes some time to switch locations on the SSD, and it has to be accounted for. (even when reading just a single sample file sequentially, each access will take 0.1m, but because we will store a block of data each time we read, we can ensure seamless playback by reading the next block before we have finished playing the first block. For a chord, though, don't have any data to begin with, so there is an unavoidable time delay between each note, OR, we wait until we have a block of data from all samples, and then play all notes together, which results in a longer latency before we hear a sound, but when we do, we'll hear all notes sound at exactly the same time)



Thanks - that thread helps a bit, but I'm still not totally clear, and in fact, I haven't yet ruled out that it could in fact be interleaving the damper resonance samples with the normal pedal-up sample data. Yes, obviously I was wrong about the mic perspectives, but I'm still not convinced I'm wrong about the idea - I was only using the mic perspectives to illustrate the general theory. To be absolutely sure, I'd like to ask Korg how many stereo notes could be sounded simultaneously, for a simple instrument with no damper resonance or anything. (btw, is the streaming synth engine multi-timbral?)

Greg.

As I understand it, SSD is essentially an array of NAND flash. NOR flash can be accessed as RAM, and it would work the way you'd want... as I said, the issues with that are the high expense and the slow write time. As I understand it, the Nord pianos load the entire samples into NOR flash, there is no RAM pre-load, so that's what you want... i.e. essentially "streaming" (if you want to call it that, which is a stretch of the definition) directly from flash, no RAM, no pre-load, and it works since NOR operates as a kind of RAM (as opposed to NAND operating as a kind of storage). The issue again is the expense, and that changing the contents takes so long. I suppose, if the architecture supported streaming, you could use NOR flash to hold the pre-loads with the rest streaming from SSD, essentially using NOR flash in place of RAM, but in the case of Kronos, I think the only benefit would be faster boot, which would be offset by higher cost and the loss of the ability to switch to an entirely different pre-load in 2 minutes, as it would take far longer than that to rewrite the NOR pre-load. (This is largely a repeat of some of what was said earlier, just in a slightly different context.)


In the piano engine (which has no instruments except piano), the answer is 100 stereo notes simultaneously. You can turn the damper resonance off, but I think the max remains 100 notes.


I believe so. The non-piano streaming engine is HD-1, which supports up to 140 voices, and combis of up to 16 timbres. I'm not aware of there being a limit as to how many of the timbres can be streaming, but this is not an area I am well versed in.

Also...


This is reminiscent of some old conversations here, and I remain open but unconvinced. If NAND (page access, storage) flash could that easily be accessed as random access "RAM" (as NOR flash is), why would NOR exist, and why would companies like Nord, Kurzweil, and Yamaha pay so much more to use it? Are you aware of any microprocessor controlled device at all that uses no RAM, no NOR flash that can behave as RAM, but instead uses only NAND flash and the kind of controller you are talking about in order to provide RAM-style access to NAND? With NAND being so much cheaper, it seems to me that someone would be using it that way if it was really so easy to do.