When I installed the huge Rotterdam organ, I carefully studied the manual and online suggestions, and did a LOT of experimenting. I've learned a lot of things that would be useful to a newbie, and I summarize them below. I invite experts here to comment and criticize, with perhaps the end goal of producing a newbie rank tuning guide to supplement what's in the manual, So, here are my thoughts and a suggested tuning algorithm:
Rank performance tuning notes
Computer memory is cheap, and crucial for good performance. Get as much as you possibly can. 64 GB is a reasonable choice; the cost is marginally more than 32 and the performance difference is huge on a large organ.
Plan on doing many (slow!) trials of various rank configurations. If you go with your first try, you are either amazingly lucky or too tired today to tweak properly. Come back tomorrow.
Use the Audio/MIDI performance panel to monitor your results. Free memory, CPU load, and the polyphony bar graph, which shows polyphony relative to your specified limit, bear close watching.
Here's how to change rank loading parameters. I may be dense, but it actually took me a while to figure this out. Select a single rank or group of ranks on the 'Load organ with rank...' list. The current parameters for a single rank will be displayed. If you have selected a group of ranks, any parameters that have conflicts within that group will be highlighted. In order to make a change, you must change something. Anything. As soon as you change a parameter, Hauptwerk's memory of all settings for that selected rank or set of ranks will be updated. DO NOT CLICK OK YET! That will start the long, slow loading process unnecessarily. You don't need to click OK to update the value; just changing it will save the new value. So you should set up your entire trial parameter set before clicking OK.
Static polyphony (what performance looks like just holding down a bunch of notes) is deceiving, as it is overly good looking. To get a more accurate reading, rock your hands on the keyboard quickly.
The reason for the difference is that tail processing (handing the reverb of the performance space) adds 'hidden' polyphony which greatly increases the CPU load.
Hauptwerk has to process not only the notes that are down each instant, but the also the echoes of notes that were just down but now released. This dynamic figure is the one to pay attention to, not static results.
There is a large correlation between polyphony and CPU load. Higher polyphony processing requires higher CPU load.
Thus, if you are experiencing excessive CPU load (even a TINY venture into the red zone produces terrible distortion!), you must reduce the polyphony limit on the polyphony display.
By doing so, when your polyphony demand gets to the polyphony red zone (your specified limit), Hauptwerk will automatically drop notes that it believes are least important, thus reducing the CPU load.
However, dropping notes significantly impairs realism, so your goal should be to get your specified polyphony limit as high as reasonably possible, while preventing the CPU load from EVER touching the red zone.
This is the end goal of rank performance tuning, and achieving it is the topic of this discussion.
First, a simple no-brainer. Many Sonus Paradisi organs split some ranks into a 'left component' and a 'right component'. By default, these load in stereo mode. Change this to mono. There will be no sound quality hit whatsoever, and memory usage will significantly drop, to your great advantage.
The most important tradeoff you will face involves compression. There are two competing limitations:
Uncompressed ranks require more memory than compressed (especially large difference at 20 bits), but they avoid the significant CPU load of uncompressing compressed ranks.
Thus, uncompressed ranks will give you better polyphony at the cost of increased memory usage.
There is no performance penalty, and lots of benefit, to increasing your memory usage to very close to what's installed in your computer. You probably should not go right up to it, in case some operating system process suddenly kicks in. But get pretty close. This lets you maximize polyphony. (Addendum... Hauptwerk recommends not so close, perhaps 67-75 percent. I'm running Rotterdam at about 90 percent on a 64 GB machine with no problems so far, but my computer is strictly dedicated to Hauptwerk, with no competing programs running. And a crash may be waiting for me right around the corner.)
Using 16-bit samples should be an absolute last resort, and then only for little-used ranks. Memory usage is half of higher resolution, which is great, but the quality tradeoff can be huge. Especially for soft stops and trail-off of reverb, hiss and quantization noise can be audible and annoying.
There is little audible quality difference between 20-bit-and 24-bit samples, but there is no memory difference at all, since both are stored in 32-biit words.
If your rank is uncompressed, definitely go with 24-bit resolution versus 20-bit; there is small sound improvement with no memory penalty.
If your rank is compressed, you will gain a lot more memory saving by using 20-bit samples, which compress far better than 24-bit samples. So if a rank is compressed and memory is critical (the usual situation!), choose 20-bit resolution versus 24-bit. You lose little sound quality and gain much memory saving. There is relatively little point in compressing a 24-bit rank.
Uncompressed samples use a lot of memory, whether the organist selects those stops or not. An unused stop consumes as much memory as a frequently used stop.
But the CPU load penalty paid for compressed stops, which reduces vital polyphony, is paid ONLY when the stop is engaged and played by the organist.
Thus, one should tend to compress rarely used stops, where you gain a lot of memory saving but pay a low price in polyphony reduction.
Those stops which the organist will use often should be uncompressed if possible to keep the polyphony-reducing CPU load to a minimum.
A good process for implementing these operations is to begin with every rank compressed at 20-bit resolution. This will provide minimal memory usage, though with relatively poor polyphony. If at this point your are using most of your available memory, you are in trouble. The best solution is to upgrade the memory on your computer. If this is not possible, you have only unpleasant alternatives. You could go with this and make do with whatever polyphony you get. Alternatively, you could change the resolution of some rarely used stops to 16 bits, understanding that these stops will have impaired sound quality. This will buy you a lot of memory usage reduction, which you can then use to change the most-used stops to uncompressed 24-bit resolution. This will reduce the CPU load for those stops (and only those stops), allowing you to cautiously increase your specified polyphony limit. Understand that this has a risk, because if you put on several of the rarely used compressed stops, the CPU load from uncompressing them in realtime could put your CPU into the red zone, causing very serious noise (loud crackling) problems. The bottom line is that if you have too little memory in your computer, you will face a range of alternatives, all of which are unpleasant.
Let's assume that with all ranks compressed at 20-bit resolution you have plenty of memory to spare. Now we proceed to take advantage of that idle memory.
Pick a few of the stops that you plan to use most often, especially in Tutti situations. (If there are stops that you will use often, but only as solo stops in small registrations, don't worry about them. Polyphony problems tend to occur most often with large registrations.) For these stops, change them to 24-bit uncompressed. In a surround situation, you might as well change the rear channels in addition to the front, as they will be called into play in parallel with the front channels. After changing a handful of stops, click OK to load the organ and go do something else while it loads. Then see how much memory is used. Hopefully you will still have a lot left to spare, so you can uncompress more stops, working from most used to least used. Keep doing this until you've hit the memory limit. Then test your dynamic polyphony as described at the beginning of this article, and set your polyphony limit accordingly.
There are two more things to consider, which are discussed in detail in the manual and which should be considered. I have avoided mentioning them here, because their treatment in the manual is excellent.
For individual ranks, you can disable certain aspects of how samples are loaded, such as multiple sample loops and related items. Also, the engine allows global disabling of certain types of processing, affecting all ranks simultaneously. I have found these to be of secondary importance, compared to compression and sample resolution, but others may disagree, and these options should certainly be studied in the manual. In my opinion, disabling such items has too high of a cost in sound quality compared to polyphony gain, although this is a deeply personal perception. My advice is to begin with all such Hauptwerk processing turned on. Follow the algorithm shown above to determine the ideal compression and sample rate for each rank. If satisfactory results are not obtained (polyphony is still too low when RAM is maxed out) then selectively disable individual rank processing as described in the manual and see if CPU load drops enough to be worth the sound quality reduction. As a last resort, disable some global processing, knowing that you will likely pay a high price in sound quality and versatility. Buy more RAM if you find that too many ranks need to be compressed! And in the unfortunate situation that all ranks are uncompressed, yet your polyphony is still so low that you need to begin disabling processing options, your CPU is too slow. You might consider buying a newer, faster computer.
The bottom line is that the method described above has the advantage of involving little or no impact on sound quality, aside from polyphony. When you get into disabling Hauptwerk processing such as rank sample loops and global engine processing, you are impacting sound quality, and you may well find that, perceptually, the tradeoff of increased polyphony versus deterioration of other aspects of sound is not worthwhile. Of course, this is a highly subjective perception, and everybody is different in what they value.
Tim
Rank performance tuning notes
Computer memory is cheap, and crucial for good performance. Get as much as you possibly can. 64 GB is a reasonable choice; the cost is marginally more than 32 and the performance difference is huge on a large organ.
Plan on doing many (slow!) trials of various rank configurations. If you go with your first try, you are either amazingly lucky or too tired today to tweak properly. Come back tomorrow.
Use the Audio/MIDI performance panel to monitor your results. Free memory, CPU load, and the polyphony bar graph, which shows polyphony relative to your specified limit, bear close watching.
Here's how to change rank loading parameters. I may be dense, but it actually took me a while to figure this out. Select a single rank or group of ranks on the 'Load organ with rank...' list. The current parameters for a single rank will be displayed. If you have selected a group of ranks, any parameters that have conflicts within that group will be highlighted. In order to make a change, you must change something. Anything. As soon as you change a parameter, Hauptwerk's memory of all settings for that selected rank or set of ranks will be updated. DO NOT CLICK OK YET! That will start the long, slow loading process unnecessarily. You don't need to click OK to update the value; just changing it will save the new value. So you should set up your entire trial parameter set before clicking OK.
Static polyphony (what performance looks like just holding down a bunch of notes) is deceiving, as it is overly good looking. To get a more accurate reading, rock your hands on the keyboard quickly.
The reason for the difference is that tail processing (handing the reverb of the performance space) adds 'hidden' polyphony which greatly increases the CPU load.
Hauptwerk has to process not only the notes that are down each instant, but the also the echoes of notes that were just down but now released. This dynamic figure is the one to pay attention to, not static results.
There is a large correlation between polyphony and CPU load. Higher polyphony processing requires higher CPU load.
Thus, if you are experiencing excessive CPU load (even a TINY venture into the red zone produces terrible distortion!), you must reduce the polyphony limit on the polyphony display.
By doing so, when your polyphony demand gets to the polyphony red zone (your specified limit), Hauptwerk will automatically drop notes that it believes are least important, thus reducing the CPU load.
However, dropping notes significantly impairs realism, so your goal should be to get your specified polyphony limit as high as reasonably possible, while preventing the CPU load from EVER touching the red zone.
This is the end goal of rank performance tuning, and achieving it is the topic of this discussion.
First, a simple no-brainer. Many Sonus Paradisi organs split some ranks into a 'left component' and a 'right component'. By default, these load in stereo mode. Change this to mono. There will be no sound quality hit whatsoever, and memory usage will significantly drop, to your great advantage.
The most important tradeoff you will face involves compression. There are two competing limitations:
Uncompressed ranks require more memory than compressed (especially large difference at 20 bits), but they avoid the significant CPU load of uncompressing compressed ranks.
Thus, uncompressed ranks will give you better polyphony at the cost of increased memory usage.
There is no performance penalty, and lots of benefit, to increasing your memory usage to very close to what's installed in your computer. You probably should not go right up to it, in case some operating system process suddenly kicks in. But get pretty close. This lets you maximize polyphony. (Addendum... Hauptwerk recommends not so close, perhaps 67-75 percent. I'm running Rotterdam at about 90 percent on a 64 GB machine with no problems so far, but my computer is strictly dedicated to Hauptwerk, with no competing programs running. And a crash may be waiting for me right around the corner.)
Using 16-bit samples should be an absolute last resort, and then only for little-used ranks. Memory usage is half of higher resolution, which is great, but the quality tradeoff can be huge. Especially for soft stops and trail-off of reverb, hiss and quantization noise can be audible and annoying.
There is little audible quality difference between 20-bit-and 24-bit samples, but there is no memory difference at all, since both are stored in 32-biit words.
If your rank is uncompressed, definitely go with 24-bit resolution versus 20-bit; there is small sound improvement with no memory penalty.
If your rank is compressed, you will gain a lot more memory saving by using 20-bit samples, which compress far better than 24-bit samples. So if a rank is compressed and memory is critical (the usual situation!), choose 20-bit resolution versus 24-bit. You lose little sound quality and gain much memory saving. There is relatively little point in compressing a 24-bit rank.
Uncompressed samples use a lot of memory, whether the organist selects those stops or not. An unused stop consumes as much memory as a frequently used stop.
But the CPU load penalty paid for compressed stops, which reduces vital polyphony, is paid ONLY when the stop is engaged and played by the organist.
Thus, one should tend to compress rarely used stops, where you gain a lot of memory saving but pay a low price in polyphony reduction.
Those stops which the organist will use often should be uncompressed if possible to keep the polyphony-reducing CPU load to a minimum.
A good process for implementing these operations is to begin with every rank compressed at 20-bit resolution. This will provide minimal memory usage, though with relatively poor polyphony. If at this point your are using most of your available memory, you are in trouble. The best solution is to upgrade the memory on your computer. If this is not possible, you have only unpleasant alternatives. You could go with this and make do with whatever polyphony you get. Alternatively, you could change the resolution of some rarely used stops to 16 bits, understanding that these stops will have impaired sound quality. This will buy you a lot of memory usage reduction, which you can then use to change the most-used stops to uncompressed 24-bit resolution. This will reduce the CPU load for those stops (and only those stops), allowing you to cautiously increase your specified polyphony limit. Understand that this has a risk, because if you put on several of the rarely used compressed stops, the CPU load from uncompressing them in realtime could put your CPU into the red zone, causing very serious noise (loud crackling) problems. The bottom line is that if you have too little memory in your computer, you will face a range of alternatives, all of which are unpleasant.
Let's assume that with all ranks compressed at 20-bit resolution you have plenty of memory to spare. Now we proceed to take advantage of that idle memory.
Pick a few of the stops that you plan to use most often, especially in Tutti situations. (If there are stops that you will use often, but only as solo stops in small registrations, don't worry about them. Polyphony problems tend to occur most often with large registrations.) For these stops, change them to 24-bit uncompressed. In a surround situation, you might as well change the rear channels in addition to the front, as they will be called into play in parallel with the front channels. After changing a handful of stops, click OK to load the organ and go do something else while it loads. Then see how much memory is used. Hopefully you will still have a lot left to spare, so you can uncompress more stops, working from most used to least used. Keep doing this until you've hit the memory limit. Then test your dynamic polyphony as described at the beginning of this article, and set your polyphony limit accordingly.
There are two more things to consider, which are discussed in detail in the manual and which should be considered. I have avoided mentioning them here, because their treatment in the manual is excellent.
For individual ranks, you can disable certain aspects of how samples are loaded, such as multiple sample loops and related items. Also, the engine allows global disabling of certain types of processing, affecting all ranks simultaneously. I have found these to be of secondary importance, compared to compression and sample resolution, but others may disagree, and these options should certainly be studied in the manual. In my opinion, disabling such items has too high of a cost in sound quality compared to polyphony gain, although this is a deeply personal perception. My advice is to begin with all such Hauptwerk processing turned on. Follow the algorithm shown above to determine the ideal compression and sample rate for each rank. If satisfactory results are not obtained (polyphony is still too low when RAM is maxed out) then selectively disable individual rank processing as described in the manual and see if CPU load drops enough to be worth the sound quality reduction. As a last resort, disable some global processing, knowing that you will likely pay a high price in sound quality and versatility. Buy more RAM if you find that too many ranks need to be compressed! And in the unfortunate situation that all ranks are uncompressed, yet your polyphony is still so low that you need to begin disabling processing options, your CPU is too slow. You might consider buying a newer, faster computer.
The bottom line is that the method described above has the advantage of involving little or no impact on sound quality, aside from polyphony. When you get into disabling Hauptwerk processing such as rank sample loops and global engine processing, you are impacting sound quality, and you may well find that, perceptually, the tradeoff of increased polyphony versus deterioration of other aspects of sound is not worthwhile. Of course, this is a highly subjective perception, and everybody is different in what they value.
Tim
Last edited by TimM on Thu Mar 23, 2017 3:59 pm, edited 2 times in total.