Instruments need to be batch-resaved

For the longest time, Kontakt had an issue whereby if you saved an Instrument on a Mac, the same NKI would open very slowly on a PC (until re-saved on that machine). This has been fixed in Kontakt 5.6 and above but will still affect any instruments made for Kontakt 5.5 and below (as all Spitfire instruments are).

If you're experiencing slow loading times, it's more than likely down to this issue. Giving the instruments a quick Batch Re-save will more than likely fix this issue. You can view a tutorial of mine on Batch re-saving by clicking here!

Windows Defender (or a similar anti-malware/virus scanner) is scanning each sample on load

In Windows 10 Microsoft changed the behaviour of the built-in virus scanner Windows Defender  so that it scans every single file as it's opened on your PC (regardless of whether it's an executable, or just data). Some Spitfire instruments can contain hundreds of thousands of samples and a brief scan of each one can massively increase loading times.

If you've tried batch re-saving and are still experiencing slow loading times, it's worth checking that you've excluded any sample folders or sample drives from the Windows Defender scan list. Microsoft has a tutorial on their site that walks you through the process and can be viewed by clicking here.

Similarly, other virus scanners can cause loading time issues, so it's worth checking if any that you have installed and configuring them to ignore your samples/instruments.

Kontakt MIDI channel assignment option is set to Omni

If your patches always default to the Omni  MIDI channel when loaded into Kontakt, this may be the reason behind your missing release samples. Take a look in the Kontakt options by hitting Options in the toolbar. Kontakt's options are grouped into pages which you can navigate using the tabs to the left of the dialog. Select Handling and look for the option labelled MIDI channel assignment for loaded patches.

If it is set to omni (as in the picture above) give it a click and select 1st free from the drop-down menu. Close the options dialog and restart Kontakt and see if that has fixed the missing releases problem.

This issue is caused by a combination of several features within Spitfire Instruments; the persistent releases dynamics, flexible CC configuration via Learn MIDI CC# automation  and a Kontakt quirk with how CCs are stored/recalled within scripts. A workaround has been introduced as of BML TROMBONES and will be included in all Spitfire product updates going forward.

Changing the MIDI channel of a loaded instrument

When loading an instrument Kontakt's default behaviour is to assign it to the first free MIDI channel available. However, there may be many times that you want to move an instrument/articulation to a different channel. You may notice that your Spitfire instrument no longer plays release samples after doing so.

The problem is very simple to fix in one of two ways:

• Press the ! restart button on Kontakt's toolbar (see the first section for details)
• Wiggle the Dynamics (and possibly the Vibrato) slider a little.

Those two methods should revive those release samples. This problem's actually caused by a similar Kontakt quirk to the omni issue mentioned above. When you load an instrument, various CCs (including the persistent releases CC) are initialised with values matching the Spitfire UI sliders. However Kontakt never tells the script that the user has switched the MIDI channel and so there's no way for the instrument to 'reinitialise' them when this happens. Hitting ! or wiggling the sliders achieves this. That said, I spent quite a bit of time and effort figuring out a work around for this which is included in BML TROMBONES and will find its way into other products as they're updated.

Changing the MIDI channel of a loaded instrument

All Spitfire instruments are powered by Sandbox , the system that unifies all the features across products and makes the internals of Spitfire instruments work correctly. There are some pretty innovative features within Sandbox which rely on certain CCs to work. When designing the system I picked CCs that were unused in the MIDI standard and relatively out the way. However there's always the chance that you've coincidently decided to use the same ones. Here are a list of CCs to avoid using on the same MIDI channel as a Spitfire instrument:

• CC 103
• CC 104
• CC 106
• CC 110
• CC 111
• CC 116
• CC 117

If you've used any of those on the same channel as a Spitfire instrument (either mapping a control to a specified CC or just using another instrument on the same MIDI channel) you may run into problems with releases disappearing, or acting erratically. Try to utilise different CCs and see if that helps. It's probably best to try to stay under CC 100 just in case.

Kontakt's CPU overhead protection is turned on

When you don't have any round-robins to use the previous technique, there is an old trick to thicken the sound a little using the tuning and transpose options available within Kontakt.

With the power of modern-day CPUs and the trend moving towards offline-rendering, I'd recommend setting these to disabled. Unless you're using an instrument with unoptimised code or an excess of groups and zones you shouldn't experience much in terms of CPU overheads. Simply click the Options button on the Kontakt toolbar, select the Engine page and look for the 'CPU Overhead protection' option.

Kontakt's buffer is set too low

When an instrument is utilising the Direct-from-disk (DFD)  streaming, Kontakt will load a tiny portion of each sample into memory. This pre-load buffer gives Kontakt a little bit of data in RAM that it can play while it's streaming in data from the disk. Kontakt allows you to configure how big this buffer is on an instrument or global level so that users can optimise for SSDs or other fast data storage.

If you have a fast solid-state drive you can get away with setting the buffer as low as 6KB most of the time with no problems or streaming issues. However, there is a quirky bug in Kontakt that affects loop points when using a low DFD value. Sometimes a sample will begin to drop just as it reaches the loop point (usually related to increased data-stress during cross-fades between the start/end of the loop region). When this happens you may see a little red light flicker on the toolbar where it shows the Disk status ( ) and it will continue to drop on this exact same sample at exactly the same point in time.

There are a couple workarounds for this issue:

• Completely restart Kontakt. 99% of the time this will solve the problem until it happens again
• Set your DFD preload buffer to a slightly larger value. This may work better in the long run

Personally I tend to just keep it at 6KB and restart when I experience the problem. It happens very rarely (and randomly) and I would rather have that little bit extra RAM from using a lower preload buffer.

Running out of voices

Spitfire libraries are huge projects developed by human beings. Sometimes we simply make a mistake (or Kontakt decides to make one for us) that we either didn't spot, or are preparing for an update. One of the more common ones is to leave the voice limit count on its default setting of 32. While this may have been a considerable amount of voices a few years back, with multi-mic libraries and extensive all-in-ones, it's easy to soar past this limit now.

If you've spotted an instrument that seems to have a low Voices Max  value, it's easy to change.

You can then save this new patch if you don't want to update it every time you load (as always, remember to keep a backup of the original instrument files). Feel free to ping an email to Spitfire if you encounter any issues like this so that they can be addressed and fixed in official updates.

No Sustain pedal support in BML Mural

BML Mural does not currently support the use of CC64 to sustain a note within Kontakt. This has been fixed and will be addressed in the upcoming 1.1 release but there is a workaround if you can't wait. Unfortunately release samples will not work correctly with this workaround so I would suggest trying to utilise your DAW's built in sustain functionality if possible first.

To enable the sustain pedal in a mural patch, simply click the Kontakt Edit mode button ( or ) and click Instrument Options button if a dialog does not appear.

From the Controller page, change the topmost option MIDI Controller #64 (Sustain Pedal) acts as  from CC only to Sustain Pedal + Controller. Hit close and the sustain pedal should now work (though as mentioned, the release samples will not work correctly).

Legato patches do not function correctly if the pedal is held

This affects most instruments, not just Mural. Unfortunately this is a limitation within Kontakt (and the reason Mural was initially completely disabled). I'm investigating ways to fix this, but I can't imagine there will be sustain pedal support in the foreseable future. The only workaround for now is to use a DAW that provides internal sustain-pedal support. One such example is Image-Line's FL Studio.

High CPU usage when using a non-switch pedal controller in piano instruments

Recent Spitfire piano instruments (Felt piano, plucked piano, etc.) utilise cool new functionality to play piano pedal sounds as you press and release the sustain pedal on CC64. When I was scripting this I mistakenly expected sustain pedals to only be in a single state of on  or off . A somewhat CPU intensive process happens in the script when toggling the sustain pedal but it works fine when toggled once and not very often.

However, if you're utilising a pedal or controller on CC64 (breath controller, slider, ramping pedal, etc.) that can go gradually from values 0-127, you may experience bursts of high CPU if you ride CC64. This has been fixed in the latest Sandbox and will be addressed in upcoming updates, but until then a workaround is to only set the CC64 value to 0 or 127.

CPU buildup when changing CCs, riding the mod wheel, etc.

On lower-end systems (or setups not optimised for multithreading) Kontakt may act a little CPU-hungry when you wiggle the mod wheel, ride the vibrato slider, etc. This is an unfortunate side-effect of all-in-one  patches that contain lots of mic sets and groups. There are a few things you can do:

• Have a read of my Optimising (Part 1 - Mics)  blog entry to learn how to completely remove unneeded mic signals.
• Utilise the more CPU-friendly instruments provided in the _Individual brushes/patches_ and _Economic brushes_ folders.
• Roll up (or minimise) the instrument's UI. Sometimes this can help when lots of controllers are being utilised

An unpurged articulation (or instrument) doesn't seem to make a sound

When developing Spitfire instruments part of the post-process stage is to collect all the articulations and transfer them into the all-in-ones, overlays and individual-patches As you'll know, the Spitfire UI provides you with a way to purge individual articulations. However if they're are purged in one patch and then moved to another, sometimes the appearance of the icon ( ) may not match the actual purge status. When this is mistakenly done post-process, you'll end up with an articulation that looks like it's loaded when it hasn't.

It's very easy to fix. Simply hit the purge icon to 'unload' the articulation and then hit it again  to reload. This will solve a false-purge problem.

Another common problem related to the post-processing stage is when a patch that contains a lot of articulations is split into individual ones. Sometimes it may have gone unnoticed that the first articulation was not selected in the final patches. In this case, you'll have an instrument that loads perfectly fine but does not have the first (only) articulation selected and ready to play. In these instances you can do the following:

• Click the articulation stanza lock icon ( ) and select Unlocked artic.
• Click the notation icon to select the articulation

The articulation should now be working and ready to play. You can save the NKI so that you don't have do this every time you load it.

The Dynamics slider does not work correctly if two Spitfire instruments share a MIDI channel

While this has been addressed in the latest version of Sandbox (and so fixes will roll out as products are updated), I figured it may be useful to include details and workarounds here.

If two older  Spitfire instruments are placed on the same MIDI channel within a single instance of Kontakt you may experience problems with them not responding to CC1 correctly. One or more of the instruments may stop responding to CC1 changes audibly. There are several ways to work around this:

• Upgrade to the latest version of the Spitfire instrument. This issue has been fixed in quite a few products since it was discovered.
• Control dynamics with CC103 rather than CC1. This CC provides direct control of the dynamics tables within Spitfire instruments.
• Utilise multiple instances of Kontakt allowing the instruments to share a MIDI channel without conflicting each other.

This issue is a combination of a Kontakt scripting quirk to do with how CCs are accessed/modified, and how Spitfire instruments provide a flexible way for users to reassign CC controllers. It's a very obscure bug and happens only under certain circumstances, DAWs and audio setups. While most products should have updated to address the problem the above workarounds should help with older patches.