Piano World Home Page Forums Our Most Popular Forums Digital Pianos - Electronic Pianos - Synths & Keyboards alternatives to pianoteq? (since some of you say it doesn't

When you guys refer to the playability of these software pianos what is the main contributing factor? Is it the number of velocity layers? This is the obvious advantage modeled pianos have over sampled as far as I can see.

And with the narrow sound which Temperament is talking about, having an acoustically sound setup to monitor is important as Aeons Holle pointed out, what about having the ability to layer the recordings of multiple mic placements once you've got that? Of the three pianos I'm looking at only one gives you a range of mics to play with, and another (Galaxy) says they considered this but decided against it as it introduces more problems than it would be worth.

What is the consensus on these questions?

Playability is a bit of a squirrely concept. Mostly it has three elements:

1. Does the piano respond correctly to all sequences of pedal and key correctly? Partial pedal is one issue. Another example is repedaling. For the most part the best VST's do at least most of these correctly. Some new VST's, even pretty good ones, don't see the need to handle some of these cases, though.

2. Is the relationship between incoming velocity and sound natural? Some people complain that sampled VST's don't have extreme enough fff or ppp (or that you can't get there with a normal keyboard, which seldom gets to velocity 127). In any case, sampled pianos are made from recordings that were pulled from a sampling session and may not correspond to any particular velocity, so it's possible for them to set up a velocity curve in which the timbre doesn't change where and as much as expected. Further, some sampled pianos do not blend the layers across velocity levels, so you get the same timbre at velocity 67 and 68, for example.

3. Modeled pianos have benefited from marketing that has persuaded people that there's a playability difference. We go in expecting to find it, so we do, even if we can't define what playability differences there are or what the shortcomings of the sampled VST's are.

what does VST stand for?

There are a number of terms people use to refer to software pianos, some of which are probably not technically correct. VST is one of the more common terms you hear here, although I think not all software pianos are VST's. You can wikipedia VST for details. When I use it, I am generically referring to software pianos.

Aeons Holle, I am badly occupied for a week or so and cannot do much experiments nor document this in detail. Some qualitative remarks: I think the beneficial effect I definitely have and enjoy can be attributed to the mere fact to have a more processed sound out of the spatialiser. This type of processing is probably adding some phase changes/enrichments to the by compressed phase image out of the mics. (Beside of using a moderate convolution reverb provided by the instrument like "Jazz Club").

Just my assumption. This very positive effect is definitely there, my son has noticed is also immediately. It is not a sudden pleasent "wow" at the first moment, by far not, but the sound gets wider, you get a background feeling for the sound source and the previously tiring intrusive presence of punctual sound source is tamed, getting a context. Is a matter of playability also.

I don't have Ivory, there is the original "narrow perspective" not a bottleneck or to a lesser degree and therefore it brings not that much improvement.

Another interesting observation I could make with Kontakt sampled instruments: to change interpolation algorithm of Kontakt (HQI) to perfect (instead of standard, high) an to chose 192 KBit Bitrate for my EMU0404 USB I could get some minor audible improvement, but this one was not thus emphasised as this effect of the spatialiser. (I am constantly retuning my instruments, so the effect of HWI with normal stretch tuning could be even lesser.)

Some other experience with Galaxy and Reaper (or perhaps other DAW with spatialiser)?

I agree that these are vitally important issues.



Setting up the velocity curve correctly for use with a given keyboard is all-important. It radically changes the timbre range and response when playing. I suspect many people's objections to the "best" sampled pianos are because the velocity curves are not optimized properly for their keyboard.

I also suspect latency settings have a major affect on how people perceive the playability of sampled pianos vs modeled pianos, which is a much bigger problem with sampled pianos (because of drive access time to the samples). There is a range of latency (buffers around 256 samples) that affect the feel and response of playing before the latency because obvious. I believe you need buffers of 128 samples or less to avoid those effects. I can certainly tell the difference between playing with 256 vs 128 even though the difference doesn't appear audible at first impression.

I disagree with this. The latency of disk-streaming software pianos has almost nothing to do with the latency of the disk. The reason is that the very first part of all the samples is stored in RAM, and so when you play a key, the first part of the sample is already there, ready to play. The rest of the sample, on disk, is simultaneously read in the background, so that when the first bit has finished being played, the next bit is ready, providing seamless playback.

Now, I know there can be secondary affects. I am well aware that you observed an improvement in polyphony when you increased the sample buffer size, and of course when you increase the sample buffer, latency increases. Generally, though, I assert that the latency of software pianos is by and large seperate to the latency of the storage system.

Greg.

Very good point.

James
x

gv: I'm not having trouble getting fff from my VSTs. ppp is bit more difficult, but I attribute that to my ham-fisted ways, not to the piano or the software.

Virtual Studio Technology.

http://en.wikipedia.org/wiki/Virtual_Studio_Technology

But that's the whole point. You have to increase the buffer size to accommodate more voices because you have to read more samples off the disc. Not all of the sample is pre-read and stored in RAM. Any software piano program manual will tell you this and it is easy to show by trying it. Reduce the number of voices to a small number and you will see that you can greatly reduce the sample buffer size and hence reduce the latency. The amount of buffer needed for processing samples is small compared to the size of the buffer needed to accommodate reading the samples. Use an SSD vs a hard drive and the effects on necessary buffer size (latency) are obvious.

Oh boy. I always thought it was safest to leave it linear to not interfere with the velocity curves of the DP How does one even go about getting the right setting? Is it the same for all 88 keys?

Macy: I still think that you are describing a very secondary affect. The process of streaming audio to the audio interface is seperate to the process of reading the sample data.

Your original comment, I think, could easily be misconstrued by some people to mean that if they have say, a drive with a 20ms access time, and they exchange it for a drive with a better/faster access time of, say, 10ms, that their latency will be halved. IMHO, they will not necessarily notice ANY change in latency. What they will notice will probably be a reduction in polyphony, because the latency directly affects the throughput that the disk is capable of sustaining.

Just for example, I am absolutely confident that if I were to switch from my internal SATA 7200rpm drive, to an external USB drive of 5400rpm, that I could leave my ASIO buffer at the best/minimum size of 128 samples. I would certainly notice a reduction of polyphony, and perhaps if I were to really push the disk, I might be able to eek out a bit more polyphony my increasing the ASIO size, but I really think that's a secondary affect.

The reason the pre-load buffer has an effect on the polyphony is that as the pre-load size is increased, the amount of data that the sample player reads each time, from a given sample file, increases in proportion to the pre-load size. The larger this read request size, the higher the throughput of the disk, and hence the higher the polpyphony. (with the absolute maximum throughput being the sequential transfer rate, but that can never be reached) (note that I'm referring to Kontakt in particular in all this - that's the software I have looked at most carefully so far)

Greg.

Macy:
I've just tried my external 5400 rpm drive, using Kontakt 3.5, and the Sampletekk White Grand. OS is Windows 7, CPU is a mobile Core 2 Duo @2.4GHz. (i.e - nothing at all special) I used the maximum Kontakt preload (240k) without varying it all yet. It was just a quick test, and I did not do it as carefully as I should. However, I have not yet witnessed any improvement in polyphony when increasing the ASIO buffer size. I started out on 128 (@44.1kHz), and found that I get very roughly 60 voices. I then quadrupled the ASIO size (to 512 samples), and the polyphony stayed roughly the same. I can't be sure whether there was a slight improvement or not yet - I need to test more carefully using MIDI files.

Moreover, I have not heard any glitches either. Typically, when the ASIO buffer size is too small and causes problems, little clicks can be heard. What I do notice is voices being dropped - i.e - a note will be sounding, and then it will suddenly stop when it shouldn't, and it never comes back. I have found that this is the typical behaviour of the disk being maxed out. Naturally I watched the voice count in Kontakt, and the dropouts did correspond with a reduction in the displayed voice count.

And, of course, the perceived latency when I use an ASIO size of 128 samples, when I use the slow disk, is nice and fast - just like the internal disk.

I stress that I am already using the very best (smallest) ASIO size available on my audio interface, despite the fact that I do not have an SSD. And this is using a pretty old laptop.

Greg.
p.s As I keep saying to anyone else who wants to do some testing - it is imperative to either reboot between each test, or clear the disk cache inbetween each test. Otherwise, there is a great risk of falsely high polyphony results, due to the extra caching that occurs by virtue of the operating system's disk cache. Try and play the same performance each time you do the test, and clear the disk cache inbetween each test. The easiest way to clear the disk cache on Windows is to use the Sysinternals utility called "Rammap", and use the command Empty | Empty Standby List.

p.p.s Note that the White Grand appears NOT to be using any sample compression. (I think if I were to upgrade Kontakt, I would actually be able to save the instrument with the samples being compressed). I realise that you brought to our attention that the mainstream Kontakt pianos almost certainly use compression, greatly reducing the data rate from the disk. (big selling point!)

Macy:
I've now tested it more carefully, using MIDI files, and ensuring that each Note-On maps to a seperate sample file. So, the polyphony number displayed by Kontakt equates directly to the number of simultaneous disk streams.

The result for this particular 5400rpm USB disk, for this specific test and for this specific layout of the sample files on disk, is very close to 51 streams.

Increasing the ASIO buffer size still does not make any difference. (or if it does, it is a very tiny difference that I haven't bothered to test for yet)

Reducing the pre-load by half (240k down to 120k) makes it fall over immediately when I feed it the same 51-voice MIDI file. (which is exactly what I would expect) I didn't determine the new lower polyphony for this reduced pre-load.

I still did not hear any glitches that I would associate with a problem with the ASIO buffer size - only complete note dropouts, due to the disk not being able to keep up.

All I can say is that this is all behaving exactly how I would have expected. ;^)

Greg.

Thanks for the explanation.
If I have time I will try this experiment with Vintage D instead of Ivory.

Anything can be misconstrued, and that is what you are doing here. I never said what you are saying above. Latency is NOT directly proportional to disc access time. Latency depends on the audio buffer length plus any additional delays in sample processing. IF you can reduce the audio buffer length, you will reduce latency. There are many factors (including the voice limit you set, additional processing such as convolution reverb used, size of pre-load buffers, your CPU speed, the disc access time, the disc interface rate limit, etc. etc.) that affect the size of the audio buffer you need to use, and therefore the latency that you need to use.

What I said was that latency can be a much bigger problem with sampled pianos than modeled pianos because of drive access times. IF disc access time is limiting the number of voices that can be played (whether voices are cut off prematurely by the program - a less objectionable but still objectionable problem, or if slow disc access actually creates dropouts) then using a longer audio buffer will eventually fix that problem (because there is more time to read the disc). So if one uses a longer audio buffer to solve a slow disc problem they will then get longer latency - and longer latency affects the feel of playing a software piano, even before it is overtly recognizable as an audio delay.

This following is simply an undeniable fact. If you get Slow Disc warnings on your software piano (they flash the words Slow Disc on some programs) you will be able to stop them, and the objectionable audio effects caused by them, by increasing the audio buffer length to some larger length, which of course increases the latency. I wrote a lengthy post about doing this and provided information for the effective disc reading rates of both a hard drive and SSD in another thread. I also provided data on how many additional voices could be used with the SSD vs the hard drive at the same audio buffer length (same latency), or that I could reduce the buffer length (reduce latency) by using the same number of voices with the SSD vs the hard drive.

I also indicated somewhere in the same thread that Ivory II (as well as some other pianos that use large sample libraries) must stream from disc at much faster average rates than Kontakt. The Ivory II American D has 49 GB of samples compared to the 4.23 GB for the Vintage D. The Kontakt Vintage D never exceeded about 7 MB/s from the disc using 256 voices on my Mac, but Ivory II required about 60 MB/s with 80-100 voices (voices are not counted the same by Ivory II and Kontakt). So in the experiments described in your other replies in this thread, your voice limits are probably not being limited by disc access times, but by processor speed. As I noted in that thread, I've never seen a Slow Disc indication or issue with a Kontakt piano and a mechanical hard drive.

In any event, the simple fact that Slow Disc messages (if you have that problem) can be eliminated by increasing the audio buffer length makes my point that if you have slow disc access issues you may be avoiding them by using a longer audio buffer that increases latency.

But all of this is really peripheral to my original point (because you have singled out disc access as one possible cause), if the audio buffer is too long (for any reason) the increased latency will affect playability.

------

Here is an excerpt from the original comment where I posted disc access times of SSD vs hard drives with Ivory II.

I agree that you didn't say it, but I think it could be misconstrued in the way I suggested. I could be wrong about that, but that was/is my opinion.



I mostly agree with all this, however my testing to date suggests that in Kontakt (in my specific config) the pre-load has no or very little affect on the required sample buffer, and hence the latency. The pre-load changes how much data is read from each sample each time a read is made, and thus it changes the number of head seeks per unit of time, which then directly affects the data rate that can be sustained from the disk. This affects polyphony, not latency. Obviously if I were to keep decreasing the sample buffer size, though, there would be a point where it would start to cause problems, because the lower the sample buffer, the higher the CPU load (more audio driver interrupts per second or whatever). I have re-tested now using an internal disk (to get data rate up, and hence the CPU usage up a bit), and even when I go down to a sample buffer of 64 samples, it still doesn't seem to affect the polyphony. (~85 voices at both 64 samples and 512 samples). I had to switch to ASIO4ALL on the internal audio interface to be able to go down to 64 - my USB audio interface has a lower limit of 128. Now, I haven't yet actually tried playing normally, for long periods of time, using a sample buffer of 64. I'm simply saying that when I was feeding Kontakt the test MIDI files (many simultaneous Note-Ons), I didn't notice any clicks/pops.



I am not very comfortable with this statement at all, despite the results of your own testing. I certainly haven't experienced this yet.



The "audio buffer" is the buffer is simply a buffer that the sample player application fills with sample data, and then hands over to the audio driver. It has nothing to do with the process of reading data off the disk, except that as this buffer size is decreased, it does increase the general load on the system. If the bottleneck is primarily the disk, then by far the best way to relieve that bottleneck is to increase the disk read transfer size, which is completely seperate to the audio buffer size. In Kontakt, the pre-load size changes the disk read transfer size, and of course does not change the audio buffer size.

EDIT: Re-reading your comment here again, I think just perhaps, that you have a basic misunderstanding of the function of the "audio buffer". I completely agree that the longer the access time, the more time is needed to read the disk. However, what gives the system this time is seperate buffering to the audio buffer. Initially, it is the pre-load buffer. The audio-buffer is nowhere near large enough. When a note is first played, the first little audio-buffer-size worth of sample data is read from the pre-load buffer, immediately, without involving the disk at all. It may stream some more audio-buffer-size worth of chunks from the pre-load buffer without initiating a disk access as well. The amount of audio sent to the audio driver before a disk access is initiated would depend on the size of the pre-load buffer. At some point, a disk access would be initiated. In the mean time, audio can be continued to be streamed from the pre-load buffer.
Now, when the data from disk is ready, it will be deposited into another buffer area that would behave the same as the pre-load buffer. (I think the pre-load buffer proper would always have to be maintained with the initial attack data) This data of course must be ready before the initial pre-load data (that was loaded at instrument load time) has finished being streamed to the audio driver. So, it appears to me that you may be confusing the function of the audio buffer with the pre-load buffer.

Aside from this, I re-iterate that I completely accept that there could be secondary effects. For example, the shorter the audio buffer, the shorter the time between audio driver services (e.g interrupts of some sort), and thus the more sensitive the audio streaming will be to other high priority processes & drivers. This is rather system/config dependent though. I maintain that the main reason to get a faster disk is to improve polyphony - not latency, and that's why I objected to the statement you made. (I know there are other benefits, such as faster load time & less pre-load RAM)
[end edit]



It is VERY deniable IMHO. ;^) You asked me to test it, and I did, and I did not find any evidence to support your assertion whatsoever! (I am not denying the results of your testing, though) When I maxed out my disk, upping the sample buffer size didn't do anything to improve it. (or should I go higher than 512 samples?) I would be keen to try Ivory on Windows. (unfortunately I don't have it)



I've re-read the post. There is one piece of information I don't think you provided, and it might be important:
Using the FW 800 disk, did you carefully determine the maximum polpyhony/disk-throughput (i.e - no dropouts and/or disk warnings) using a sample buffer of 128 samples, and then determine the maximum polyphony/throughput using 256 samples? I.e - I know that increasing the sample buffer to 256 stopped the problem, but how much better did it become?

Greg.
p.s Tried to test EWQLP, but it's performing dreadfully with my torture MIDI files. For investigation.

I've managed to get a result from EWQLP. I had to introduce a time delay between each Note-On, and at the moment I'm at a whopping 100ms (0.1s). I need to look into this further, but:

The polyphony I can achieve at the moment is ~30 from my internal 7200rpm SATA drive. Cf 85 for Kontakt. Huge difference. (I believe EWQLP is 48kHz/24-bit, and my Kontakt instrument is 44.1kHz/24-bit, so not much difference there. Both are uncompressed as far as I can determine).

Once again, varying the ASIO buffer size between 64 and 512 didn't make any difference that I could detect.

I tried varying all the Play settings, but none of them made a difference either. I notice that the RAM size (down the bottom right-hand corner of the Play window) doesn't change, no matter what I do. I'm sure it USED to, so something's changed along the way. Given that the RAM size doesn't change, it could well be that Play's equivalent to Kontakt's pre-load isn't changing either, which would explain why I can't vary the maximum realisable polyphony. I am able to inspect the system to determine the disk transfer size to prove this conclusively, but I haven't bothered yet.

I am very confident that I am maxxing out the disk, because if I repeat a test without clearing the Windows file system cache, the polyphony is much higher.

I have not determined how fragmented these particular EWQLP samples are, or how closely they are all located together on disk. This can make a big difference.

EDIT: I have iterrogated EWQLP, and I have found that the disk transfer size DOES change - it changes when the Maximum Voices engine setting is changed. At the minimum setting, it reads 32kBytes at a time. At 512 voices, it still reads in blocks of 32k, however it does 9 back-to-back reads each time it reads from a given sample file, making an effective logical read size of 288k. I don't know why the polyphony doesn't improve as the Maximum Voices is increased.
Regarding the RAM size display that I referred to, I suspect that I noticed it change when loading and unloading mics. I don't remember whether I ever checked to see whether it changed when any of the engine settings were changed, so please ignore my initial concern for that.

Greg.

A bit off-topic, but since this thread has gone all "technical" mode anyways, maybe some tech-guru about these things can explain how, for example, Vintage D can achieve the same (or even better) quality with it's 4,2 GB compared to 49 GB of Ivory?

Different technology, recording/sampling process, compression , etc?