Steven Slate Drums on Receptor running Kontakt 3.5

RELATED
PRODUCTS

Post

haha I want your wife :D....hm but I think I made it exactly your way. (the installation of ssd) I made the actiavation via service center and the weird thing was, that it worked :O What did the support say? I use the ssd platinum version. May ot makes a difference? Sry that I couldn t help ya :/

Post

The tech support at Muse Research has finished individually helping me for the time-being. Given that a representative from SSD has stated there are people successfully running it on their Receptor, I would appreciate any suggestions anyone might have in general about installing this sort of thing on a Receptor. I have the EX version, but all of the expansion packs. The only person who has responded on this forum is using Platinum. Is this true for everyone usings it successfully?

I feel no shame in sharing my communications with Tech Support, considering they have decided to "punt" with me for now. Hopefully it helps anyone else wondering if they can put SSD onto their Receptor.

%%%%%%%%%%%%%%

-Me
"I posted a question on the KVR audio forum, asking about putting Steven Slate Drums onto my Receptor 2 running Kontakt 3.5. I received a response on the forum from a representative from SSD, to contact MUSE Research because there are already people successfully running the software on their Receptor.
Obviously there is no installer to download off the plugorama website, so what do I need to do to use an "expansion pack" inside of Kontakt 3.5? Please respond to my posting on the forum.



-Gary Grove
(Plugorama Support)
Not sure why it is not on Plugorama.com but it is just a Direct install software. So just search for it on your DI and it will come up.
Thanks,
Gary


-Me
Thanks for your response.
I don't have Steven Slate Drums when I search for it in Direct Install. I have upgraded my Receptor Tools software, but it still doesn't appear. What do I need to do to find it?


-Gary Grove
(Plugorama Support)
Sorry I messed up. Was logged in differently and gave me a false search find.

So just install it on your computer then when it is installed take all the library files (NKI, NKX etc) and info files and drop them in the NI samples folder. Then in kontakt add libraries.
Thanks,
Gary



-Me
Thanks for your help!
I had already installed SSD on my computer. I copied the entire "Steven Slate Drums EX Library" folder off my computer onto my Receptor in "Program Files/Native Instruments/Sample Libraries/" folder. I refreshed my DB inside of Kontakt, and then hit "Add Library". After selecting the SSD folder, the SSD Library appeared. I went through the Service Center Offline Installer successfully, and the "Activate" button disappeared. When I attempt to load either an 'instrument' or a 'multi,' I receive the message "This patch is corrupt and cannot be loaded." Nothing loads then.

Should I have tried something different?



- Me(again, after no response)
Do you think it would be better for me to move files over individually rather than the entire folder? Kind of like you were describing with NKI, NKX, etc?



-Kevin Bryson
(New guy, not Gary, Plugorama Support)
We are looking at this issue in great detail, and attempting a few different methods for installing steven slate drums. We will report back to you once we have found a successful method.
Kevin

%%%%%%%%%%%%%%%%%

More than anything else learned from the exchange, it is assuring to know that a Direct Installer specifically for SSD is in testing currently. I am definitely looking forward to that.
Maybe Superior Drummer 2 will also be included in the Direct Install! I bet that will make Carl (on the forum) happy, as well as myself.

Post

Hi Eric,

I don't want to start an off-topic discussion, but I can't resist to react to your post... ;-)

>For those of you that come across this discussion and have no interest in the >theory behind the discussion, the important things to understand are this:
>1) Sound does not get any better than at 44.1k just by having a higher sampling rate

Agree

>2) Sound does not get any worse by digitally converting 44.1k to any >higher sampling rate

Don't agree. For an impression for what might get wrong try to create an image with 1024 interleaved vertical black and white lines. Then increase the horizontal resolution from 1024 to 1100 (with rescaling).

>3) Using a higher sampling rate is to maximize computational efficiency, which >allows for decreased latency/delay.

Don't agree at all. As noted above, many more computations are necessary at higher samplerates. The decreased latency comes from the fact that the same amount of bytes (e.g. a buffer size of 32) are played faster.

Fedde

Post

Fedde,
Thanks for you persistence to set the record straight on the issue of sampling rate conversion and the impact on computational efficiency of buffer size (I wouldn't mind if someone expressed the same persistence towards getting SSD onto my Receptor). I appreciate your consideration on this topic, as I get the impression that we both at least agree it is a very important topic for musicians and sound engineers to understand.

I believe you have come up with a very useful example for understanding this topic.
However, it is important to understand a difference between analog and digital information. I get the impression from your example that you may be attempting to mix continuous information with discrete information, which may be the source of confusion. It is always important to remember the function of the D/A converter when representing information like sound (or color) as discrete information.
I will even simplify your argument further for illustration. I believe you are asking: "What value (black or white) would be assigned if more samples are introduced over the space?"
A more basic example would be: "Suppose there are two lines, one black and one white. If a third line is introduced in-between, what color should it be?" The basic answer is: "as long as the sampling rate is twice the frequency and filtering is used to prevent higher frequency change from occurring, this third line is extraneous."

Although I would typically attempt to explain concepts without the use of mathematics for everyone on the forum to understand, I will make an exception here because you seem to at least take the basics into consideration when evaluating 44.1k -> 88.2k conversion. Although it would take work to prove that up-sampling by twice the amount can in fact perfectly reconstruct the signal, you have expressed previously that making this assumption is OK, so I will start from here unless you would like a deeper explanation.

Given that up-sampling by an integer multiple of 2 will result in perfect reconstruction of the signal, I assume you will agree down-sampling by an integer multiple of 2 will also result in perfect reconstruction of the signal (as long as the sampling rate is greater than twice the largest frequency). This would be the case if I have an audio signal sampled at 44.1k and I convert it to 88.2k then back to 44.1k.
To cut to the chase, I get the impression that you have no complaint with sample rate conversion when it is based on an integer multiple, but you are concerned about what happens if I want to convert from 44.1k -> 48k because it doesn't appear to be an integer multiple.

Here is the math: 44.1k can be up-sampled by a factor of 160, making the new sampling rate: 44.1k*160= 7056k samples per second. Then 7056k can be down-sampled by a factor of 147, making the new sampling rate: 7056k/147 = 48k.
Integer conversion numbers can be selected for any sampling rates including 44.1k -> 44.2k, etc.

Given that there are only three viable sampling rates other than 44.1k for SSD to be converted to, it makes perfect sense to have the re-sampling from 44.1k automatically take place for each sample when SSD is loaded in Kontakt rather than in real-time.


%%%%

To address your other concern about latency, we both agree that 32 sample buffer at 88.2k will result is a basic latency that is half of the basic latency for a 32 sample buffer at 44.1k because the 32 samples occur in half the time. I believe we would also both agree that a buffer size of 64 at 88.2k causes more computations than 32 samples at 44.1k (although they are the same basic delay time) because of the initial cost of the Fast Fourier Transform, as well as the extra multiplications during filtering.

I suppose where we would disagree is that my working definition of "efficiency" includes not only processing speed, but also dictated by the inherent latency. I would argue that a 32 sample buffer at 88.2k is more "efficient" because it allows for both fast processing as well as low latency.
Using a 32 sample buffer at 44.1k (as described originally in this post by Zappler) is likely an "inefficient" use of his 3.33 GHz dual core Receptor because I can bet that he was not taking full advantage of his system processing resources.

I should not have labeled this strictly "computationally efficient" because that term typically refers to the least number of computations, as you were correctly pointing out.


Eric

Locked

Return to “Muse Research and Development”