Piano Sampling Question

Posted by: peterws

Piano Sampling Question - 01/12/13 06:15 PM

A DP is basically an AP sampled in some way, we all know that. My question is, why the difference in sound between the DFP and AP? The AP has all the depth and character,the DP has none, we are reliably and often informed.

But isn`t the peripheral sounds/resonances also part of the sample? Is the problem to do with processing, where these other sounds are removed, or in the positionong of the microphones? or something else . . .

Maybe this has been discussed elsewhere here.
Posted by: o0Ampy0o

Re: Piano Sampling Question - 01/12/13 06:33 PM

It is often discussed everywhere but a quick answer is that a recording will always be played back through a sound system. The sound system is confined to a compressed directional delivery. Even if an omini-directional sound system exists it would have to take on the physical form of an acoustic piano in order to produce the identical sound. The different nuances come from a variety of locations and from a variety of shapes and materials. Each resonates and bounces of their relative surroundings uniquely. If it could be captured accurately it would have to be played back accurately which it cannot.
Posted by: peterws

Re: Piano Sampling Question - 01/12/13 06:37 PM

It shouldn`t be difficult to capture the sound. People do it all the time on Youtube, and we hear it as such . . .
Posted by: o0Ampy0o

Re: Piano Sampling Question - 01/12/13 07:02 PM

I think the future will be a very loud society. With the mp3, ear buds, YouTube, preference for bass and surround sound of affordable home theaters every kid today will be close to deaf by the time they reach 30 years of age.
Posted by: peterws

Re: Piano Sampling Question - 01/12/13 08:00 PM

Pardon?
Posted by: o0Ampy0o

Re: Piano Sampling Question - 01/12/13 08:58 PM

Originally Posted By: peterws
Pardon?

Peter,

The post I was responding to looked like light-hearted sarcasm given the poor quality of YouTube audio.

Were you serious about this?

Originally Posted By: peterws
It shouldn`t be difficult to capture the sound. People do it all the time on Youtube, and we hear it as such . . .
Posted by: Tyruke

Re: Piano Sampling Question - 01/12/13 09:55 PM

I've wondered about this issue as well. Especially with Yamaha digital pianos

If I were to play a Yamaha CF IIIS acoustic piano and listen with my own ears it would sound one way.

If I were to listen to a professional recording of someone playing a Yamaha CF IIIS I believe it would still sound the same to me even though I'm listening through headphones or speakers. I know it wouldn't sound EXACTLY the same, depending on various things like quality of my speakers or headphones, but I think the sound would be there.

Now when I play a Yamaha P155 digital piano, with samples from the CF IIS, there is a significant difference in the sound. Maybe it is because of the lacking resonances and all the interactions of the sound and the various materials of which the piano is made. Whatever it is, I still believe the digital sounds good, but very different from the piano from which it was sampled.
Posted by: Charles Cohen

Re: Piano Sampling Question - 01/12/13 10:37 PM

Originally Posted By: Tyruke
. . .

Now when I play a Yamaha P155 digital piano, with samples from the CF IIS, there is a significant difference in the sound. Maybe it is because of the lacking resonances and all the interactions of the sound and the various materials of which the piano is made. Whatever it is, I still believe the digital sounds good, but very different from the piano from which it was sampled.


All the things you mentioned, and in addition:

The P155 uses a "stretched" sample set. The C and D (for example) are re-tuned samples of a C#. For the count of _really sampled_ pitches look at the "DPBSD Project" thread.

The P155 uses a sample of the start of the note (1 - 2 seconds long), and then "loops" a sample of the decay. So some of the subtle "beating" between individual strings in a note, is lost.

The P155 (I think) doesn't properly simulate the acoustic piano's "key-down" resonances. On the acoustic, if you hold down C3 (without striking the string), and play the chord C5/E5/G5, the chord picks up the overtone resonances of the C3. I don't think the P155 does that. Again, the DPBSD thread has a number of tests for similar behavior.

The acoustic piano has a tone quality (independent of volume) that changes _continuously_ as touch goes from ppp to fff. The P155 has (I think) 4 "velocity layers" (a sample at ppp, p, f, fff , for example). Those "velocity layer" samples are blended together smoothly (we hope!) in an attempt to match the changes in the acoustic's tone as the MIDI "keyboard velocity" goes from 2 to 127.

As price goes up, the quality of the simulation improves. You can get DP's that use full-length samples, and that are more careful about simulating everything that an acoustic piano does.

But they're expensive. Part of that extra cost is faster electronics, and more-sophisticated software for it.

If the "thinness" of the P155 sound starts to bother you, I suspect the next logical step is to a "software piano" -- a computer-based piano "sound generator", driven by the MIDI signals from the P155 keyboard. It's way cheaper to buy one of those, than to buy a Nord Piano (to pick one high-end example).

. Charles
Posted by: dewster

Re: Piano Sampling Question - 01/12/13 10:42 PM

Why DPs don't sound like APs (let me count the ways):

1. Cheap speakers / tiny amplifiers
2. Stone age sample compression (looping, stretching, few velocity layers, etc.)
3. Weak / fake sounding / completely absent sympathetic resonance
4. We keep buying them so they have little / no incentive to improve them
5. Serious players replace internal sounds with PC software

Did I leave anything out? [EDIT] Oops, Charles beat me to the roll call of shame. And I left out "perhaps NAMM this year yadda yadda."
Posted by: Tyruke

Re: Piano Sampling Question - 01/12/13 10:56 PM

Originally Posted By: Charles Cohen

If the "thinness" of the P155 sound starts to bother you, I suspect the next logical step is to a "software piano" -- a computer-based piano "sound generator", driven by the MIDI signals from the P155 keyboard. It's way cheaper to buy one of those, than to buy a Nord Piano (to pick one high-end example).

. Charles


I actually don't own a p155 myself, but have heard numerous recordings on YouTube, and played it many times at various music stores. I just used that piano as an example because I've heard both a CF IIIS and played and heard the P155.

I have also played software pianos and noticed that the sounds were much closer to the actual pianos they sample. I guess it has to do with what you were saying, Charles (looped and stretched samples).

Is it too difficult to use recordings of all eighty-eight keys and the full length of the notes for digital pianos than for a computer running software pianos?
Posted by: MacMacMac

Re: Piano Sampling Question - 01/12/13 11:38 PM

It's not a question of difficulty. It's the cost.
Originally Posted By: Tyruke
Is it too difficult to use recordings of all eighty-eight keys and the full length of the notes for digital pianos than for a computer running software pianos?
Software pianos run on a computer. These computer-based piano libraries vary in size, with some as small as 1 GB, many in the 4 GB to 8 GB range, and some bigger still. Disk drives today have capacity sufficient to store all that (and more).

In contrast, digital pianos have no disk drive so the samples must be stored in a read-only memory. ROM storage is MUCH more expensive than disk storage, so their piano samples are much smaller (to reduce the sample size and to reduce the cost). But this forces a reduction in quality.

Result: The best software pianos are better sounding than any digital piano, and even the cheapest software pianos are better than most digital pianos.
Posted by: peterws

Re: Piano Sampling Question - 01/13/13 02:53 AM

"It shouldn`t be difficult to capture the sound. People do it all the time on Youtube, and we hear it as such . ."

Ampy, Youtube quality isn`t brill,
But you hear those resonances still!

Being serious, I would have thought it would be difficult to eliminate them when or even after the sample is taken. . .
Posted by: o0Ampy0o

Re: Piano Sampling Question - 01/13/13 03:48 AM

Peter,

Are you saying that you hear desired sounds in recordings of DPs that you do not hear when playing a DP?
Posted by: Temperament

Re: Piano Sampling Question - 01/13/13 05:42 AM

Peter, I had (and some others) had say a lot to this issue in previous topics, my thesis was that sound perpective is the major challange with sampling and that micing is inherently narrowing this perspective.

Stereo sound contains more spacial information than light: through the phase information in sound image you can theortically an infromation about the depth of the different sound sources contributing to the sound in you ear. Beside of having the phase differences in otherwise similar sound images enable us to determine the direction of the sound source, to determine the dimensions of the sound source (a punctual one or something with an extension.)

So the microphone perspective is a fix encoded information in the sound image, hereby a very aidibly present but not obvious narrowing factor.

As you have noted, the close micing is the preferred samplig perspective, to be able more freely mixing and afterprocessing with other effects (convolution revrb, etc.). If you are record ing the samples with instrument noises and reverb (from instrument body+ambience), you are sticking with these fixated parameters restricting instrument options and to some extent playability.

How to heal Achille's heal of sampled pianos

And more than that: I was able due to this insights even to enhance my SW instruments with Kontakt VSTi-s within Reaper (Galaxy VintageD/Vienna Grand) - using the builtin spatialiser very significantly:Perspective enhancement by using spatialiser
The effect I felt was totally convincing, I am now pleased with my arrangement - for the first time I can concentrate fully on playing music. I am considering to open a separate topic for this, because I feel this simple enhancement option so important for all of us VST users and I am very curious of the opinion of others (so far very little feedback).
Posted by: peterws

Re: Piano Sampling Question - 01/13/13 06:47 AM

Originally Posted By: o0Ampy0o
Peter,

Are you saying that you hear desired sounds in recordings of DPs that you do not hear when playing a DP?


No. But you hear all the resonances of the acoustic when it is played through Youtube. And in a strange way, my own DP sounds much better after recording . . . tone wise that is!
Posted by: peterws

Re: Piano Sampling Question - 01/13/13 06:52 AM

Temperament;

I`m havin` trouble in my `ed
Understandin` what you just said . . .
Posted by: peterws

Re: Piano Sampling Question - 01/13/13 06:59 AM

Charles

"The P155 uses a sample of the start of the note (1 - 2 seconds long), and then "loops" a sample of the decay. So some of the subtle "beating" between individual strings in a note, is lost.

The P155 (I think) doesn't properly simulate the acoustic piano's "key-down" resonances"

That I can understand . . .Cheers man
Posted by: o0Ampy0o

Re: Piano Sampling Question - 01/13/13 05:33 PM

Originally Posted By: peterws
Originally Posted By: o0Ampy0o
Peter,

Are you saying that you hear desired sounds in recordings of DPs that you do not hear when playing a DP?


No. But you hear all the resonances of the acoustic when it is played through Youtube. And in a strange way, my own DP sounds much better after recording . . . tone wise that is!

DP manufacturers are aiming to present the most important part of a sound in the purest form possible within the constraints of the technology.

YouTube videos may capture a shotgun spray of sounds showing that all sorts of things can be picked up by a microphone yet the quality of the sound is too poor to present as the sound in a digital piano.

The extra ambience/resonance would require larger storage capacity, a stronger engine and better delivery of audio in speaker systems to fully appreciate. To present significantly better sound sampling in a DP is impractical. It comes down to drawing a line somewhere and making the best of what fits.

EDIT: The above is my theory and opinion only.

Also regarding your own recordings, generally speaking and not knowing the methods you use, the recording will be played back through a sound system which changes your spacial perception towards what you are accustomed to listening to in a commercial recording (some is a psychological perception of improvement) and will have received some additional enhancement from the recording device. Even if it is only slight, it is geared towards creating a better presentation of the recording.
Posted by: MacMacMac

Re: Piano Sampling Question - 01/13/13 06:39 PM

Regarding this "... to present significantly better sound sampling in a DP is impractical."

I completely disagree.

I interpret "better sound" as that which today comes from a software piano library. At present, this calls for a PC or Mac.

But there's no reason why an adequate computer could not be added into a digital piano.

I run piano software on an old computer. It's a lame old laptop, but it's adequate. You would not need as much computing (or cost) inside of a digital piano because so much of the laptop guts could be omitted:
- No need for a big, heavy, expensive battery.
- No need for an expensive Windows or Mac O/S.
- No need for a wired or wireless network card.
- No need for a display.
- No need for a keyboard ... the piano already has the necessary controls and buttons.
- No need for a graphics card.
- No need for the laptop sound card ... the piano already has a sound system.

And if the processor on my meager laptop can handle piano software on top of a general purpose O/S with all of its attendant bloat, an even lesser CPU would serve adequately in a piano free of all that excess.

I wouldn't expect to find a low-end piano with all that. But it's already being done in the Crumar (sp?). Surely Kawai and Yamaha could do likewise (and better) in their high-end products.

But they don't! (Waiting for dewster to enter ...)
Posted by: o0Ampy0o

Re: Piano Sampling Question - 01/13/13 06:52 PM

Well I would agree with your disagreeing but I was making a general comment on common DPs and was not trying to cover every possibility.

Of course one could be made.

Originally Posted By: MacMacMac
I completely disagree.
Posted by: gvfarns

Re: Piano Sampling Question - 01/13/13 07:04 PM

The interesting thing to me is that evidence points to DP manufacturers skimping on the storage space, not CPU. They have very short samples with looping and blending, etc., instead of a great big samples that just stream with little further processing. Perhaps there is some issue of throughput. I don't know.

In this forum we are not DP designers, but it is hard to reconcile the progress in computers and software pianos to the apparent lack of progress in DP's. I actually wish I had a better idea of what the constraint really is. Presumably with four companies vying for the market, if there were low-hanging fruit it would have been plucked by now.

I have to think there must be some reason commodity hardware isn't as attractive an option as it seems to us.
Posted by: ONfrank

Re: Piano Sampling Question - 01/13/13 07:05 PM

Indeed it's impractical, for if Yamaha, Roland, or Kawai sold you a DP that sounded like one of them fancy software libraries in 2013, what would they sell to you in 2014?
Posted by: gvfarns

Re: Piano Sampling Question - 01/13/13 07:10 PM

Originally Posted By: ONfrank
Indeed it's impractical, for if Yamaha, Roland, or Kawai sold you a DP that sounded like one of them fancy software libraries in 2013, what would they sell to you in 2014?


I've often had this thought (I've also wondered if Yamaha and Kawai don't want digitals competing with their acoustics but that wouldn't explain Roland and Casio).

You may be right. But if so, it's an unstable equilibrium. Any company that deviated from that strategy and actually made a big technological leap would gain a huge chunk of market share at the expense of the others. They would have to coordinate to make the oligopoly work.

More likely in my mind, the problem is the consumers: not educated enough to know/care and comparison shop effectively. That being the case things like marketing and brand name are more important than the underlying tech.
Posted by: anotherscott

Re: Piano Sampling Question - 01/13/13 08:34 PM

Originally Posted By: gvfarns
The interesting thing to me is that evidence points to DP manufacturers skimping on the storage space, not CPU.

I don't think we usually have any idea what CPU they are using.

Originally Posted By: gvfarns
instead of a great big samples that just stream with little further processing. Perhaps there is some issue of throughput. I don't know.
...
it is hard to reconcile the progress in computers and software pianos to the apparent lack of progress in DP's. I actually wish I had a better idea of what the constraint really is.
...
I have to think there must be some reason commodity hardware isn't as attractive an option as it seems to us.

It is happening. The Kronos, the Crumar, and the Receptor do exist.

I think the question people mean, then, is why isn't it happening more cheaply. What I've noted in the past is that streaming (or any method of seeing storage space as virtual RAM such that the entire data set for an operation doesn't have to be in directly accessible memory simultaneously) seems to require a sophisticated OS (i.e. Windows, Mac, Linux) and so then also the hardware those OSes require. I suppose a company could write their own OS with this functionality, but it is probably non-trivial and beyond the normal scope of their programming talents, and who knows if it would even run on notably less hardware anyway.

Anyway, if that's the case, it becomes easier to see why keyboard manufacturers can't do it that cheaply, between the fact that instrument companies can't build computers as cheaply as computer companies can, and that the specialty instrument market can't survive on the low profit margins of commodity products, and that an instrument buyer is not going to put up with the things that computer users often put up with (occasional glitches, possibly leading to need to reboot; operations that take too much time; sometimes having to fiddle with settings to get things to work right), so things do have to be optimized for the desired functionality even in a commodity-based system. That is, even Kronos, Crumar, and Receptor are doing more than tossing commodity components and stock OS into a box... though Crumar comes closest by using embedded XP and not having the system do anything beyond piano... and even they're not cheap, especially when you realize they're selling direct.

But maybe we'll see some advancement here at NAMM in a couple of weeks!

Originally Posted By: ONfrank
if Yamaha, Roland, or Kawai sold you a DP that sounded like one of them fancy software libraries in 2013, what would they sell to you in 2014?

Not too many people buy a new piano every year, and I don't think these companies are looking at that as a strategy. They'll probably be happy if you want to buy another one five years from now... and no matter what they could possibly give you today, I bet they would be able to have something better 5 years from now!

Originally Posted By: gvfarns
Any company that deviated from that strategy and actually made a big technological leap would gain a huge chunk of market share at the expense of the others. They would have to coordinate to make the oligopoly work.

I don't believe there is any coordination to limit technology. Apart from my general aversion to "conspiracy theory" thinking, I really think each company wants to do what they can to be at the head of the pack. And arguably, Korg made the technological leap you describe with the Kronos. (And in fact, that hasn't stopped people from buying Nords, Rolands, and Yamahas--even reasonably high priced ones--as they each still have their own unique advantages.) Also, the instrument companies do know that you can put a laptop on any MIDI keyboard, so they must recognize that that is part of their competition as well. And the fact that not everyone is happy with that approach is not simply a matter of it being in two pieces instead of one, so I think that whatever an instrument manufacturer does along those lines needs to address the downsides of the computer approach a little more thoroughly.

I mentioned elsewhere that it took Korg a year to get the Kronos to stream user samples (in addition to the ones they pre-designed for it), and that's with an OS and hardware that already inherently supports streaming. I just don't think this stuff is as simple as many people here seem to think it is, especially if you're looking for the rock-solid operation you'd expect in a pro instrument.

In part, what I'm saying is that I think Ivory et al work because, on the software side, Apple and Microsoft have already done much of the low-level "heavy lifting," so to speak, while also providing a relatively low-cost mass production hardware platform; and they also benefit from the fact that people are okay if they can't just fire it up and have it work perfectly out of the gate "first time, every time," because expectations are different on a non-dedicated system.
Posted by: Dr Popper

Re: Piano Sampling Question - 01/13/13 09:32 PM

Originally Posted By: o0Ampy0o
Originally Posted By: peterws
Pardon?

Peter,

The post I was responding to looked like light-hearted sarcasm given the poor quality of YouTube audio.

Were you serious about this?

Originally Posted By: peterws
It shouldn`t be difficult to capture the sound. People do it all the time on Youtube, and we hear it as such . . .


wink
Posted by: victthoe

Re: Piano Sampling Question - 01/13/13 10:25 PM

People do it all the time on Youtube, and we hear it as such .
Posted by: sullivang

Re: Piano Sampling Question - 01/14/13 02:37 AM

Originally Posted By: anotherscott
[...] though Crumar comes closest by using embedded XP and not having the system do anything beyond piano...


My understanding is that the user may put any VST they like on the system. (it comes with a 7200rpm drive, so it should be able to stream samples, too). I think Crumar confirmed this in another thread some time ago. If you're referring to the config as sold though, then yes - I think that's correct.

Regarding the Kronos - do you happen to know whether it streams samples from the SSD in the sense that it has to pre-load the attacks? The reason I ask is that I've just noticed that fast SSDs are very VERY fast now - the first one I looked at can do about 100K operations per second (= 0.01ms per read). The Kronos spec says 100 voices(*), and 100 x 0.01ms is just 1ms. I don't know what latency the Kronos has when using the SSD, but if we could tolerate about 5ms, that leaves 80% of the audio buffer time for processing of those samples, which is a lot. This could mean that it doesn't really need to pre-load at all, which would make a simpler system design. Maybe back when it was designed SSDs were not nearly this fast though.

Greg.
p.s It says 100 "dual stereo voices". If those dual stereo voices are not always co-located in the SSD, then I would need to multiply the voice count by 4 (to get the 400 raw voices they quote), and in that case the calculation doesn't look as attractive. I suspect those dual-stereo voices would be packed together, though, and that's why they quote the true polyphony as 100. Otherwise, they would have simply said "400", without any qualification.

p.p.s When I say "pre-load" - I realise it may well just put the attacks in fast FLASH or something - not actually "load" the attacks.
Posted by: dire tonic

Re: Piano Sampling Question - 01/14/13 04:56 AM

Originally Posted By: gvfarns
Originally Posted By: ONfrank
Indeed it's impractical, for if Yamaha, Roland, or Kawai sold you a DP that sounded like one of them fancy software libraries in 2013, what would they sell to you in 2014?


I've often had this thought (I've also wondered if Yamaha and Kawai don't want digitals competing with their acoustics but that wouldn't explain Roland and Casio).



Quite. Sooner or later someone’s going to blink and DPs will make the quantum jump we’ve all been craving. In any case, the marketers and retailers are unlikely to have a problem persuading some of us to buy a real strung piano for its organic form factor, its physical presence, its sound board and near-inimitable ‘sonic superiority’.

Even with the inevitable lag between the conception and realisation of a new DP in the market, I would be very surprised if we didn’t see something non-looping within the year. 16gb of solid state memory is now a drop in the ocean compared to overall costs.


Posted by: dire tonic

Re: Piano Sampling Question - 01/14/13 05:23 AM

"This could mean that it doesn't really need to pre-load at all, which would make a simpler system design"

I've no doubt that's true. Not only the read/write rates, SSD access times are absolutely blistering also.

I suppose it’ll be a few years before notebook and desktop HDDs give way more or less completely (apart from bulk storage and archiving) to SSD so software pianos have no choice but to pre-load for now.

I don't know if it's of any interest but I raided the piggy bank and bought a samsung 840 SSD last week and it's been a revelation, for the boot-up and – more importantly - loading into Kontakt. But this blew me away; prior to the SSD my acid test for setting a generous buffer - gliss the entire keyboard while holding sustain – would show a gradual climbing in Kontakt’s disk-usage meter so that after 2 or 3 seconds the bar was fully white = disk overloaded. The same test with the SSD and there’s not a flicker of movement, the meter registers nothing.


Posted by: Temperament

Re: Piano Sampling Question - 01/14/13 06:13 AM

Originally Posted By: anotherscott
...keyboard manufacturers can't do it that cheaply, between the fact that instrument companies can't build computers as cheaply as computer companies can, and that the specialty instrument market can't survive on the low profit margins of commodity products, and that an instrument buyer is not going to put up with the things that computer users often put up with (occasional glitches, possibly leading to need to reboot; operations that take too much time; sometimes having to fiddle with settings to get things to work right), so things do have to be optimized for the desired functionality even in a commodity-based system.

Completely disagree. My cheap 8 ys. old Linksys router has a Linux operating system with some elementary web server functionality. Hardly bigger than my pocket wallet, costed some 30$. I was involved in such projects previously for developing such dedicated HW/SW applications, with high reliability specifications - DPs are nothing special in this regard.

I would bet in all of these DPs is running under such an operating system already, probably a Linux derivate.

(I can remember we were astonished to find out that in 1999 to that time revolutionary seeming touch screen application for choosing meals and printing tickets in the staff restaurant of the bank central we worked at was a normal program task running under WindowsNT - a proprietary OS.)

This will now change rapidly I think.Manufacturers could explore halting back development because their targeted buyer in the classical instrument market was to a higher percentage a technically relatively conservative - not to say naive (older people without technical background and primary interests in computers). Completely different with digital photography, where development was some one decade ahead of DPs. But all of this will be changing rapidly. Facebook citizens are sophisticated enough to be able to get user of a multimedia solutions with a master-keyboard, which will become the major concurrency for DPs.

KAWAIs announced new MIDI master KB VPC is such a first sign for this kind of development.

I think even some small companies launching some HQ DPs from their garage could now enforce breaking the hegemony of the restrained development strategy of mainstream manufacturers.
Posted by: MacMacMac

Re: Piano Sampling Question - 01/14/13 07:03 AM

Most of that makes sense. But I don't see "small companies" entering the market and "breaking the hegemony ... of mainstream manufacturers". The cost is prohibitive.
Posted by: Temperament

Re: Piano Sampling Question - 01/14/13 09:59 AM

Mac, I don't think the engineering and manufacturing costs are that high at all. A small local player can bring out such a thing easily. A SW piano on the basis of a standard enginge (Kontakt) is a very small project. (You can measure it on their price, even HQ instruments cost <= 100$). A keybed on the industrial scale shouldn't cost much more, just as 40GB SSDs, cabinet is carpenter work, boxes aren't much special either...

Marketing and logistic advantage seems more to be the most prohibitive factor for newcomer.

Posted by: sullivang

Re: Piano Sampling Question - 01/14/13 12:08 PM

Looks like the real-world access times are far greater - up around 0.1ms, not 0.01ms: http://www.tweaktown.com/reviews/5128/samsung_840_pro_128gb_ssd_review/index7.html And is it true that the Kronos uses an Atom processor to talk to the SSD? Hmmmm.

Greg.
Posted by: MacMacMac

Re: Piano Sampling Question - 01/14/13 12:13 PM

Temperament: I'm talking about market-entry costs.

How can a newcomer company convince retailers to stock their products when those retailers already have showrooms full of established, well-selling products from the existing market players?

And how can a new company convince an investment banker that the firm can make a go of it? It takes a large investment to startup a company.
Posted by: dewster

Re: Piano Sampling Question - 01/14/13 12:23 PM

Originally Posted By: sullivang
Looks like the real-world access times are far greater - up around 0.1ms, not 0.01ms

MIDI takes ~1ms to send a single note on, so 0.1ms is down in the noise, no?

I don't know exactly how this test works, but it seems time to random first byte, after which sequential reads should be lightening fast.
Posted by: dire tonic

Re: Piano Sampling Question - 01/14/13 12:32 PM

- for huge corporations, economies of scale and the ability to swiftly tool up a new production line are the main deterrent to small operators, I believe.

Posted by: sullivang

Re: Piano Sampling Question - 01/14/13 12:47 PM

Originally Posted By: dewster
Originally Posted By: sullivang
Looks like the real-world access times are far greater - up around 0.1ms, not 0.01ms

MIDI takes ~1ms to send a single note on, so 0.1ms is down in the noise, no?


That's cheating. smile I want it to be able to bang out all 100 voices together, like my laptop does. I'm sure I've seen you complain about how slow standard MIDI is, too. smile Yes, though, if we allow the 0.1ms skew between notes, that makes it much easier.

Greg.
Posted by: dire tonic

Re: Piano Sampling Question - 01/14/13 01:03 PM

I’m always mystified by the ‘real world’ – I suspect my real world isn’t quite the same as anyone else’s.

I was curious about all this so I’ve just run a trial of HD tune pro for my two resident drives.

1) Bog standard Toshiba HDD, 500gb, 5400 rpm.
2) Samsung 840 ssd, 250gb (not the pro model)

Toshiba:
Max read (periphery of platter?) 76MB/sec
Min read 36.2MB/sec
Access time 17.6 ms

Samsung:
Read rate avg 173MB/sec more or less constant across the drive.
Access time 0.204ms

Coming back to my real world. My system drive is always rather clogged up with nonsense. From the HDD, boot-up used to be circa 3 minutes. With the SSD its 25 secs. I didn't bother to quantify the Kontakt test but I found the results to be stark and impressive.

On the other hand, an access time for the SSD of 0.2 ms is much less impressive than I imagined but, still, approx 80x faster than the HHD (assuming the test to be reliable).

Posted by: Temperament

Re: Piano Sampling Question - 01/14/13 04:39 PM

Originally Posted By: MacMacMac
Temperament: I'm talking about market-entry costs.

How can a newcomer company convince retailers to stock their products when those retailers already have showrooms full of established, well-selling products from the existing market players?

And how can a new company convince an investment banker that the firm can make a go of it? It takes a large investment to startup a company.

Very true, indeed. We have seen how even big companies like Kawai have sometimes their handycaps because their world wide retail chain is smaller than that of their even bigger competitor.

But I will set up a Reaper/Kontakt/VintageD konfiguration for my friend on his laptop next week with a used Fatar keyboard, and I will be a locally operating direct competitor for all of the big players :-)
Posted by: o0Ampy0o

Re: Piano Sampling Question - 01/14/13 07:08 PM

Originally Posted By: Temperament
I will set up a Reaper/Kontakt/VintageD konfiguration for my friend on his laptop next week with a used Fatar keyboard, and I will be a locally operating direct competitor for all of the big players :-)

You and your friends Cuckos, Native Instruments and Galaxy Instruments to whom you will be paying fees to use their products.
Posted by: peterws

Re: Piano Sampling Question - 01/14/13 08:27 PM

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

Re: Piano Sampling Question - 01/15/13 12:15 AM

Originally Posted By: me
I want it to be able to bang out all 100 voices together, like my laptop does.


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.
Posted by: dire tonic

Re: Piano Sampling Question - 01/15/13 03:34 AM

- thread drift...dontcha just love it!!
Posted by: anotherscott

Re: Piano Sampling Question - 01/15/13 03:22 PM

Originally Posted By: sullivang
Originally Posted By: anotherscott
[...] though Crumar comes closest by using embedded XP and not having the system do anything beyond piano...


My understanding is that the user may put any VST they like on the system. (it comes with a 7200rpm drive, so it should be able to stream samples, too).

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.

Originally Posted By: sullivang
Regarding the Kronos - do you happen to know whether it streams samples from the SSD in the sense that it has to pre-load the attacks?

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

Originally Posted By: sullivang
I don't know what latency the Kronos has when using the SSD, but if we could tolerate about 5ms, that leaves 80% of the audio buffer time for processing of those samples, which is a lot. This could mean that it doesn't really need to pre-load at all, which would make a simpler system design. Maybe back when it was designed SSDs were not nearly this fast though.

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).

Originally Posted By: sullivang
p.s It says 100 "dual stereo voices". If those dual stereo voices are not always co-located in the SSD, then I would need to multiply the voice count by 4 (to get the 400 raw voices they quote), and in that case the calculation doesn't look as attractive. I suspect those dual-stereo voices would be packed together, though, and that's why they quote the true polyphony as 100. Otherwise, they would have simply said "400", without any qualification.

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.

Originally Posted By: sullivang
p.p.s When I say "pre-load" - I realise it may well just put the attacks in fast FLASH or something - not actually "load" the attacks.

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

Re: Piano Sampling Question - 01/15/13 03:33 PM

Originally Posted By: Temperament
Originally Posted By: anotherscott
...keyboard manufacturers can't do it that cheaply, between the fact that instrument companies can't build computers as cheaply as computer companies can, and that the specialty instrument market can't survive on the low profit margins of commodity products, and that an instrument buyer is not going to put up with the things that computer users often put up with (occasional glitches, possibly leading to need to reboot; operations that take too much time; sometimes having to fiddle with settings to get things to work right), so things do have to be optimized for the desired functionality even in a commodity-based system.

Completely disagree. My cheap 8 ys. old Linksys router has a Linux operating system with some elementary web server functionality. Hardly bigger than my pocket wallet, costed some 30$. I was involved in such projects previously for developing such dedicated HW/SW applications, with high reliability specifications - DPs are nothing special in this regard. .

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.

Originally Posted By: Temperament
I would bet in all of these DPs is running under such an operating system already, probably a Linux derivate.

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.
Posted by: anotherscott

Re: Piano Sampling Question - 01/15/13 03:42 PM

Originally Posted By: Temperament
Mac, I don't think the engineering and manufacturing costs are that high at all. A small local player can bring out such a thing easily. A SW piano on the basis of a standard enginge (Kontakt) is a very small project. (You can measure it on their price, even HQ instruments cost <= 100$).

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.

Originally Posted By: Temperament
. A keybed on the industrial scale shouldn't cost much more

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.
Posted by: Kawai James

Re: Piano Sampling Question - 01/15/13 04:57 PM

Well said Scott! (x3)
Posted by: sullivang

Re: Piano Sampling Question - 01/15/13 05:13 PM

Originally Posted By: anotherscott

It is streaming piano samples, as shipped,


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

Quote:

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


Thanks for the info - much appreciated.

Originally Posted By: sullivang

I suspect that pre-load is always useful, because data cannot be executed directly from SSD,


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).

Quote:
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!


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.

Quote:
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.


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?

Quote:
Originally Posted By: sullivang
p.p.s When I say "pre-load" - I realise it may well just put the attacks in fast FLASH or something - not actually "load" the attacks.

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


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.
Posted by: anotherscott

Re: Piano Sampling Question - 01/15/13 05:53 PM

Originally Posted By: sullivang
Originally Posted By: anotherscott

It is streaming piano samples, as shipped,


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

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

Originally Posted By: sullivang
Originally Posted By: anotherscott

I suspect that pre-load is always useful, because data cannot be executed directly from SSD,


Data is not executed - instructions are executed.

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."

Originally Posted By: sullivang
Quote:
I don't think that being "co-located" is any issue at all here.


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.

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.

Originally Posted By: sullivang
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.

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.
Posted by: sullivang

Re: Piano Sampling Question - 01/15/13 06:48 PM

Originally Posted By: anotherscott

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."


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! smile

Quote:
Originally Posted By: sullivang
Quote:
I don't think that being "co-located" is any issue at all here.


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.

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.


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.

Quote:

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.


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.
Posted by: anotherscott

Re: Piano Sampling Question - 01/15/13 07:29 PM

Originally Posted By: sullivang
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! smile


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.

Originally Posted By: sullivang
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.

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.

Originally Posted By: sullivang
Quote:

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...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.


It would reduce instrument load times, because there would be NO pre-load at all.

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.

Originally Posted By: sullivang
[quote]
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.

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.
Posted by: sullivang

Re: Piano Sampling Question - 01/15/13 08:01 PM

Originally Posted By: anotherscott

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.


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.

Quote:

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.


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.
Posted by: anotherscott

Re: Piano Sampling Question - 01/15/13 08:41 PM

Originally Posted By: sullivang
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.

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.

Originally Posted By: sullivang
Quote:

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.


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 neglible, but I think it's important to be aware of it.

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.)
Posted by: sullivang

Re: Piano Sampling Question - 01/15/13 09:19 PM

Originally Posted By: anotherscott

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...


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.

Quote:
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.


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.

Quote:
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.


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.

Quote:
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.


Precisely.

Quote:
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.)


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.
Posted by: sullivang

Re: Piano Sampling Question - 01/16/13 07:24 AM

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. smile

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.
Posted by: anotherscott

Re: Piano Sampling Question - 01/16/13 09:48 AM

Originally Posted By: sullivang
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.

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?

Originally Posted By: sullivang
Quote:
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.


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.

Quote:
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.


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.

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?

Originally Posted By: sullivang
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?

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?

Originally Posted By: sullivang
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.

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/phpbb2/v...2118aa5292440dd
Multiple mic perspectives and such have nothing to do with it.
Posted by: dire tonic

Re: Piano Sampling Question - 01/16/13 12:14 PM

Originally Posted By: sullivang
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. smile

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 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...
Posted by: sullivang

Re: Piano Sampling Question - 01/16/13 02:12 PM

Originally Posted By: anotherscott
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?


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)

Quote:
What about the issue of "random access" versus "page access" as referenced on that NOR/NAND wiki page I referenced?


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.


Quote:
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?


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)

Quote:
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/phpbb2/v...2118aa5292440dd
Multiple mic perspectives and such have nothing to do with it.


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.
Posted by: anotherscott

Re: Piano Sampling Question - 01/16/13 02:45 PM

Originally Posted By: sullivang
(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)

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.)

Originally Posted By: sullivang
I'd like to ask Korg how many stereo notes could be sounded simultaneously, for a simple instrument with no damper resonance or anything.

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.

Originally Posted By: sullivang
(btw, is the streaming synth engine multi-timbral?)

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.
Posted by: anotherscott

Re: Piano Sampling Question - 01/16/13 03:20 PM

Also...

Originally Posted By: sullivang
Originally Posted By: anotherscott
What about the issue of "random access" versus "page access" as referenced on that NOR/NAND wiki page I referenced?


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.

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.
Posted by: sullivang

Re: Piano Sampling Question - 01/16/13 03:22 PM

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.

Quote:
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.


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.
Posted by: anotherscott

Re: Piano Sampling Question - 01/16/13 06:04 PM

Originally Posted By: sullivang
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.

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).

Originally Posted By: sullivang
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?

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

Originally Posted By: sullivang
I wonder why there is a voice discrepancy between the general purpose streaming engine, and the piano engine?

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.

Originally Posted By: sullivang
Is the 140 voice for HD-1 140 mono voices? Does it halve for stereo?

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.)
Posted by: sullivang

Re: Piano Sampling Question - 01/16/13 07:44 PM

Originally Posted By: anotherscott

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).


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.

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


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.
Posted by: dire tonic

Re: Piano Sampling Question - 01/17/13 04:58 AM

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!
Posted by: sullivang

Re: Piano Sampling Question - 01/17/13 05:32 AM

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

Greg.
Posted by: Dr Popper

Re: Piano Sampling Question - 01/17/13 05:37 AM

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.
Posted by: sullivang

Re: Piano Sampling Question - 01/17/13 06:01 AM

Originally Posted By: anotherscott

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.


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

Quote:

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.


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.
Posted by: dire tonic

Re: Piano Sampling Question - 01/17/13 06:02 AM

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?
Posted by: MacMacMac

Re: Piano Sampling Question - 01/17/13 07:18 AM

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? smile
Posted by: sullivang

Re: Piano Sampling Question - 01/17/13 07:30 AM

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:
Originally Posted By: anotherscott
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.


(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.
Posted by: sullivang

Re: Piano Sampling Question - 01/17/13 07:53 AM

(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.
Posted by: anotherscott

Re: Piano Sampling Question - 01/17/13 11:45 AM

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

Quote:

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.


I.e - you seemed to be saying that it is IMPOSSIBLE to do away with RAM, even if the system worked extremely slowly.

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.

Originally Posted By: sullivang
All I have been trying to prove to you that it is most certainly ENTIRELY possible for a CPU to operate [without] RAM.

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.

Originally Posted By: sullivang
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.

That makes more sense to me.

Originally Posted By: sullivang
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

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. ;-)
Posted by: sullivang

Re: Piano Sampling Question - 01/17/13 02:55 PM

Originally Posted By: anotherscott

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.
Posted by: anotherscott

Re: Piano Sampling Question - 01/17/13 03:03 PM

Originally Posted By: sullivang
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.

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.
Posted by: sullivang

Re: Piano Sampling Question - 01/17/13 03:11 PM

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! smile

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

Quoting:
Quote:

Currently, the DaVinci™ evaluation module (DVEVM) supports three boot modes: the
DVEVM can boot from NOR (default), NAND, or universal asynchronous
receiver/transmitter (UART). NOR Flash offers the advantages of one-byte random
access and execute-in-place technology. NAND Flash is not as easy to work with since
it requires Flash Translation Layer (FTL) software to make it accessible; however, due
to its lower price, speed, and longer life span, many costumers want to design with
NAND Flash instead or NOR Flash. This application report describes the process to
follow for booting the DaVinci DVEVM from NAND Flash.


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.
Posted by: kiedysktos.

Re: Piano Sampling Question - 01/17/13 07:43 PM

Originally Posted By: dewster
Why DPs don't sound like APs (let me count the ways):

1. Cheap speakers / tiny amplifiers
2. Stone age sample compression (looping, stretching, few velocity layers, etc.)
3. Weak / fake sounding / completely absent sympathetic resonance
4. We keep buying them so they have little / no incentive to improve them
5. Serious players replace internal sounds with PC software


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.
Posted by: peterws

Re: Piano Sampling Question - 01/18/13 07:54 AM

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