It is currently Thu Mar 28, 2024 3:57 am


My performance tuning for ranks

Hauptwerk software technical support only. Please make sure you have read the manual, tutorials and FAQ pages before requesting support.
  • Author
  • Message
Offline
User avatar

TimM

Member

  • Posts: 85
  • Joined: Tue Nov 15, 2016 8:18 am
  • Location: Rural Northeast PA

My performance tuning for ranks

PostMon Mar 20, 2017 9:57 am

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
Last edited by TimM on Thu Mar 23, 2017 3:59 pm, edited 2 times in total.
Offline
User avatar

mdyde

Moderator

  • Posts: 15441
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: My performance tuning for ranks

PostMon Mar 20, 2017 12:14 pm

Hello Tim,

Thanks for the excellent write-up, which I'm sure will be useful to lots of people.

I think I would add only the following brief comments:

- You've probably already seen it, but this document (linked from the 'Support | Prerequisites' section of the website) has quite a bit of general background information on polyphony, memory, and performance tuning: https://www.hauptwerk.com/clientuploads/documentation/PDF/HauptwerkBackgroundTechnicalInfoOnComputerHardware.pdf .

- In my previous tests, memory compression typically allowed about 10-15% less static polyphony overall, so Hauptwerk's polyphony management system automatically takes account of that when calculating the polyphony load. Hence you shouldn't need to make any manual adjustments to the polyphony limit for, or other allowances for, having some ranks compressed and others not.

- Turning off memory compression might also allow organs to load noticeably faster if you're using the latest (e.g. PCIe-based) very fast SSDs.

TimM wrote: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.


Probably the main RAM issue these days is with laptops, which are often limited to 16 GB (although some recent, albeit pricey, PC laptops do allow 64 GB). Current Mac laptops in particular are still limited to a maximum of 16 GB.

TimM wrote: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.


I'd advise some caution with filling the computer's RAM too completely (especially if the computer is a general-purpose one that's also used for things apart from Hauptwerk), since it risks erratic, and potentially extreme, performance issues (or even system instability, in the worst case) if some other application/process tries to do something in the background, which will inevitably happen from time to time. My experience is that it's usually safe to use about 67-75 percent of the physical RAM for Hauptwerk, depending on how 'clean' the computer is.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline
User avatar

TimM

Member

  • Posts: 85
  • Joined: Tue Nov 15, 2016 8:18 am
  • Location: Rural Northeast PA

Re: My performance tuning for ranks

PostMon Mar 20, 2017 12:34 pm

Martin - Thank you for that additional information. Yes, I studied that document carefully before beginning this project. It contains excellent explanations of what polyphony is, and its implications.

I was able to purchase a new Asus ROG laptop with sixth-gen Intel i7 quad core, 64 GB RAM, 512 GB SSD, and 1 TB spinner, for under $2000 on Amazon. At the time I thought 64 GB was overkill, but after installing Rotterdam I see that it is barely sufficient!

Tim
Offline

OrganoPleno

Member

  • Posts: 652
  • Joined: Thu Dec 03, 2009 4:08 pm

Re: My performance tuning for ranks

PostThu Mar 23, 2017 2:55 pm

TimM wrote:Computer memory is cheap, and crucial for good performance. Get as much as you possibly can. 64 GB is a reasonable choice


Maybe so, maybe not. If you are loading large Sample Sets, 64 GB will not be sufficient for best results. 128 GB should generally suffice for current-day Samples.

TimM wrote:Plan on doing many (slow!) trials of various rank configurations. If you go with your first try, you are either amazingly lucky or too lazy to tweak properly.


This is simply offensive. Some of us know what we want, and we know how to get there.

The correct polyphony setting can more easily be determined as I discussed in a previous post.
viewtopic.php?f=4&t=15957
For testing and confirmation, your approach is basically sound. To re-phrase, choose some very full registration and play some very full chords rapidly. Ideally, the CPU indicator will not go into the red because the Polyphony indicator will get there first. But not too much first. When Polyphony hits red, you want the CPU right close to the red but not quite into it. This is the ideal balance. For my installation, it always confirms the number previously determined the simple way.

For loading ranks and bits, there should be no problem if you have sufficient RAM for that Organ. Just load everything, full-featured, at 24 bits with no compression. If it doesn't fit, try it with compression. If that doesn't fit, try everything at 20 bits with compression. If that doesn't fit, you will need a computer with more RAM to get best results from that Sample Set. In the meantime, you could try omitting ranks or divisions (as you discuss at such length) but realize that you are preventing that Sample Set from ever speaking as it should.
Offline
User avatar

TimM

Member

  • Posts: 85
  • Joined: Tue Nov 15, 2016 8:18 am
  • Location: Rural Northeast PA

Re: My performance tuning for ranks

PostThu Mar 23, 2017 3:36 pm

I certainly apologize if I offended you, as no offense was intended. I was grinning as I said that, making a joke. But seriously, how many people, especially beginners to whom I addressed that, will get everything exactly right on the first try? What I was trying to do is emphasize the importance of not going with your first try. Keep tweaking, even if it gets boring. The process of tweaking a large organ can be really tedious; it took me about ten iterations to get Rotterdam working to my satisfaction, and I suspect that before long I'll tweak it again. It is too easy to just shrug shoulders and say, "Good enough."

Tim
Offline

jwillans

Member

  • Posts: 424
  • Joined: Thu Jun 16, 2005 12:30 pm
  • Location: Menston, UK

Re: My performance tuning for ranks

PostThu Mar 23, 2017 3:49 pm

OrganoPleno wrote:
TimM wrote:Computer memory is cheap, and crucial for good performance. Get as much as you possibly can. 64 GB is a reasonable choice


Maybe so, maybe not. If you are loading large Sample Sets, 64 GB will not be sufficient for best results. 128 GB should generally suffice for current-day Samples.


Is this really the case? I load the complete Salisbury in 20 bit using less than 16 GB. I appreciate that some recent sample sets have surround sound, but 128GB !!
Offline

OrganoPleno

Member

  • Posts: 652
  • Joined: Thu Dec 03, 2009 4:08 pm

Re: My performance tuning for ranks

PostThu Mar 23, 2017 3:50 pm

TimM wrote: I was grinning as I said that, making a joke. But seriously, how many people... will get everything exactly right on the first try?


The joke didn't carry. Some of us DO get everything right on the first try. Sorry if that bothers you.

TimM wrote:It is too easy to just shrug shoulders and say, "Good enough."


But to smile and say "Perfection!".... priceless.
Offline

OrganoPleno

Member

  • Posts: 652
  • Joined: Thu Dec 03, 2009 4:08 pm

Re: My performance tuning for ranks

PostThu Mar 23, 2017 3:54 pm

jwillans wrote:I appreciate that some recent sample sets have surround sound, but 128GB !!


Yes, indeed. My installation of the Goerlitz organ creates a Cache File of 74,334,498,380 bytes, which is over 69 binary Gigabytes. This is using compression. When uncompressed, the file would be approximately twice that size. I do not have the exact figure because that would be well beyond my current 128 GB capacity.

Return to Technical support

Who is online

Users browsing this forum: No registered users and 8 guests