I own SSD that runs inside of Kontakt 3.5. I have Komplete 5 running on my Receptor including the Kontakt update to 3.5 that is necessary to run SSD in general.
Is it possible to run SSD on the Receptor? Has anyone tried it? There is no 'installer' on the plugorama website for it specifically, but I am wondering about installing 'expansion packs' that just run inside Kontakt. Does everything really need its own installers?
I am going to just try to put the SSD folder into the Program Files/Native Instruments/Sample Libraries folder on my Receptor Drive. Does anyone have any better instructions or suggestions?
Steven Slate Drums on Receptor running Kontakt 3.5
-
- KVRist
- 228 posts since 12 Nov, 2005
we've run SSD 3.5 on Receptor with amazing results. We have a few bands running it live with Ddrum triggers on their acoustic drums, using Roland TD-20 for trigger box.
I'd contact MUSE.
I'd contact MUSE.
-
- KVRist
- Topic Starter
- 54 posts since 17 Dec, 2009
Thanks a lot for you quick response. I have emailed Muse Support, and will wait optimistically for a response here on the forum.
It is assuring to hear that there are other people successfully using it now. I would love to connect with anyone doing this and participating on the forum.
I was surprised that there was not more discussion I could find in the forum regarding installing SSD on a Receptor, or even SSD in general on a Receptor. I anticipate the install is pretty simple because it is really just running inside Kontakt 3.5, but I am apprehensive about haphazardly dumping the SSD sample pack into different folders on my Receptor HD to see what works.
Putting SSD on the receptor would be a nice way to tide me over until whenever Superior Drummer 2 is made available. I really shouldn't complain, BFD2.1 and Addictive Drums both run well, but SSD and SD2 would be great!
Eric
It is assuring to hear that there are other people successfully using it now. I would love to connect with anyone doing this and participating on the forum.
I was surprised that there was not more discussion I could find in the forum regarding installing SSD on a Receptor, or even SSD in general on a Receptor. I anticipate the install is pretty simple because it is really just running inside Kontakt 3.5, but I am apprehensive about haphazardly dumping the SSD sample pack into different folders on my Receptor HD to see what works.
Putting SSD on the receptor would be a nice way to tide me over until whenever Superior Drummer 2 is made available. I really shouldn't complain, BFD2.1 and Addictive Drums both run well, but SSD and SD2 would be great!
Eric
-
- KVRer
- 8 posts since 10 Sep, 2009
Hey
Im using SSD with my receptor Pro with a 3,33 ghz intel dual cpu with a buffersizer of 32 samples and having lot of cpu room.....works perfect since 10 months.....haha after our concerts the people always come and ask me how we got this awesome drumsound....:p....We are triggering our kick/toms
greez
Im using SSD with my receptor Pro with a 3,33 ghz intel dual cpu with a buffersizer of 32 samples and having lot of cpu room.....works perfect since 10 months.....haha after our concerts the people always come and ask me how we got this awesome drumsound....:p....We are triggering our kick/toms
greez
-
- KVRist
- Topic Starter
- 54 posts since 17 Dec, 2009
Thanks for jumping into the discussion, Zappler!
Can you recall how you installed SSD onto your Receptor?
What sampling rate (44.1 k - 96 k) are you using to run the buffer size of 32? Do you load all the samples into RAM in Kontakt 3.5, or stream from disk?
I usually run BFD 2.1 and Addictive Drums at 96k, 128-256 samples of buffer depending on how many instruments I load. The sustain on cymbals (increasing effective polyphony) seems to hurt computational speed, but I am like you - where I am most concerned about triggering drums only (not cymbals) live on the Receptor. It would be great to drop the latency even further with SSD, 32 samples at 96k would be insane.
I only have the IKM Total Workstation Receptor, which doesn't have the dual-core processor, but it still handles Kontakt 3.5 very well. I will let you about the performance difference on my Receptor after I get SSD installed.
Eric
Can you recall how you installed SSD onto your Receptor?
What sampling rate (44.1 k - 96 k) are you using to run the buffer size of 32? Do you load all the samples into RAM in Kontakt 3.5, or stream from disk?
I usually run BFD 2.1 and Addictive Drums at 96k, 128-256 samples of buffer depending on how many instruments I load. The sustain on cymbals (increasing effective polyphony) seems to hurt computational speed, but I am like you - where I am most concerned about triggering drums only (not cymbals) live on the Receptor. It would be great to drop the latency even further with SSD, 32 samples at 96k would be insane.
I only have the IKM Total Workstation Receptor, which doesn't have the dual-core processor, but it still handles Kontakt 3.5 very well. I will let you about the performance difference on my Receptor after I get SSD installed.
Eric
-
- KVRer
- 8 posts since 10 Sep, 2009
No problem.... I cant remember exactly but I think I just copied the SSD Folder from my Windows Pc into the Kontakt Folder on my Receptor. First you have to install it on your computer. Samplingrate is 44.1 with buffersize of 32. I cant feel any difference in latency if I use the TD 20 direct or with my receptor and SSD.
I dont know if Kontakt loads all samples into the ram :/ I just load the Vdrum presets steven made for us :p.... I just thought, that if the samples are recorded in 44,1 there is no need to use higher sample rates if the Latency works well. I think think the adat out works max with 48k. Are u using the analog out?
I dont know if Kontakt loads all samples into the ram :/ I just load the Vdrum presets steven made for us :p.... I just thought, that if the samples are recorded in 44,1 there is no need to use higher sample rates if the Latency works well. I think think the adat out works max with 48k. Are u using the analog out?
-
- KVRer
- 8 posts since 10 Sep, 2009
Ah I forgot to say, that we trigger everything in our practice room. Kick/snare/toms/hihat/2xCrash/ride and with my settings there is no problem @44.1k|32buffer. With the older firmware the kontakt player didn t work as smoth as now.
-
- KVRist
- Topic Starter
- 54 posts since 17 Dec, 2009
Cool! Thanks for the info. I will get this a try when I get off work today.
You are definitely correct in thinking that because the samples were recorded at 44.1k, that using a higher sampling rate will not improve the audio quality. In general, it is safe to doubt anyone who says they can hear a difference between 44.1k and 96k. The main purpose of using a higher sampling rate is to decrease latency, not to improve audio quality.
Without getting too nerdy, I am going to try to convince you to try out higher sampling rates to maximize the total capabilities of your Receptor.
An example: suppose you use 32 sample buffer/44100 sampling rate. The way to figure out the basic latency is: (32samplesofdelay/44100samplespersecond) = .7 ms of delay.
If you change to 32 sample buffer/48k sampling rate, then the basic latency is improved. (32samplesofdelay/48000samplespersecond) = .6 ms of delay.
If you can go 32 sample buffer/96k sampling rate, then the basic latency will be (32samplesofdelay/96000samplespersecond) = .3 ms of delay. This is less than half of the initial delay.
Note: doubling the sampling rate, doubles the work on the CPU, so it is possible to have glitches. So the best bet is to find the highest sampling rate where nothing glitches. Give it a try and let me know what you think.
Most musicians are aware that CDs are at 44.1kHz, but it should also be noted that almost all CD players up-sample to a higher sampling rate to be more computationally efficient in the processing of audio. In general, higher sampling rates are to improve computational processing by your computer, rather than to sound better.
Also, important to note: an overhead microphone 1 meter above a drumset introduces (1m/340meterspersecond) = 2.9 ms of delay based on the speed of sound. This delay is much more than using the Receptor at your settings. So don't listen to the people that hate on digital because it automatically introduces delay that "analog doesn't." Having a little delay sounds completely natural to human ears, and not distinguishable if kept to a minimum.
Unfortunately, I don't understand installing software on the Receptor very well. Your help is greatly appreciated.
You are definitely correct in thinking that because the samples were recorded at 44.1k, that using a higher sampling rate will not improve the audio quality. In general, it is safe to doubt anyone who says they can hear a difference between 44.1k and 96k. The main purpose of using a higher sampling rate is to decrease latency, not to improve audio quality.
Without getting too nerdy, I am going to try to convince you to try out higher sampling rates to maximize the total capabilities of your Receptor.
An example: suppose you use 32 sample buffer/44100 sampling rate. The way to figure out the basic latency is: (32samplesofdelay/44100samplespersecond) = .7 ms of delay.
If you change to 32 sample buffer/48k sampling rate, then the basic latency is improved. (32samplesofdelay/48000samplespersecond) = .6 ms of delay.
If you can go 32 sample buffer/96k sampling rate, then the basic latency will be (32samplesofdelay/96000samplespersecond) = .3 ms of delay. This is less than half of the initial delay.
Note: doubling the sampling rate, doubles the work on the CPU, so it is possible to have glitches. So the best bet is to find the highest sampling rate where nothing glitches. Give it a try and let me know what you think.
Most musicians are aware that CDs are at 44.1kHz, but it should also be noted that almost all CD players up-sample to a higher sampling rate to be more computationally efficient in the processing of audio. In general, higher sampling rates are to improve computational processing by your computer, rather than to sound better.
Also, important to note: an overhead microphone 1 meter above a drumset introduces (1m/340meterspersecond) = 2.9 ms of delay based on the speed of sound. This delay is much more than using the Receptor at your settings. So don't listen to the people that hate on digital because it automatically introduces delay that "analog doesn't." Having a little delay sounds completely natural to human ears, and not distinguishable if kept to a minimum.
Unfortunately, I don't understand installing software on the Receptor very well. Your help is greatly appreciated.
-
- KVRAF
- 6323 posts since 30 Dec, 2004 from London uk
This has been the subject of many debates on KVR - 44.1 vs 96. Some swear that it makes all the difference in certain realtime synth VSTIs and FX. There have been polls with blind tests etc - a nice can of wormsetarr wrote:Cool! Thanks for the info. I will get this a try when I get off work today.
You are definitely correct in thinking that because the samples were recorded at 44.1k, that using a higher sampling rate will not improve the audio quality. In general, it is safe to doubt anyone who says they can hear a difference between 44.1k and 96k. The main purpose of using a higher sampling rate is to decrease latency, not to improve audio quality.
Without getting too nerdy, I am going to try to convince you to try out higher sampling rates to maximize the total capabilities of your Receptor.
An example: suppose you use 32 sample buffer/44100 sampling rate. The way to figure out the basic latency is: (32samplesofdelay/44100samplespersecond) = .7 ms of delay.
If you change to 32 sample buffer/48k sampling rate, then the basic latency is improved. (32samplesofdelay/48000samplespersecond) = .6 ms of delay.
If you can go 32 sample buffer/96k sampling rate, then the basic latency will be (32samplesofdelay/96000samplespersecond) = .3 ms of delay. This is less than half of the initial delay.
Note: doubling the sampling rate, doubles the work on the CPU, so it is possible to have glitches. So the best bet is to find the highest sampling rate where nothing glitches. Give it a try and let me know what you think.
Most musicians are aware that CDs are at 44.1kHz, but it should also be noted that almost all CD players up-sample to a higher sampling rate to be more computationally efficient in the processing of audio. In general, higher sampling rates are to improve computational processing by your computer, rather than to sound better.
Also, important to note: an overhead microphone 1 meter above a drumset introduces (1m/340meterspersecond) = 2.9 ms of delay based on the speed of sound. This delay is much more than using the Receptor at your settings. So don't listen to the people that hate on digital because it automatically introduces delay that "analog doesn't." Having a little delay sounds completely natural to human ears, and not distinguishable if kept to a minimum.
Unfortunately, I don't understand installing software on the Receptor very well. Your help is greatly appreciated.
-
- KVRist
- 103 posts since 10 Jan, 2007
The difference between 44.1 and 96 kHz should be audible. The resampling needed to convert 44.1 kHz to 96 kHz will likely give time smear and a tiny bit of distortion (depending on the way of filtering). The question is if you like the time smear or not...
Possibly, 88.2 kHz might sound more accurate than 96 kHz (an even multiple of 44.1 kHz). But I can imagine that latency is much more important than the subtle differences in audio quality...
(personally I use 44.1 kHz because not all of my plugins support higher rates)
Fedde
Possibly, 88.2 kHz might sound more accurate than 96 kHz (an even multiple of 44.1 kHz). But I can imagine that latency is much more important than the subtle differences in audio quality...
(personally I use 44.1 kHz because not all of my plugins support higher rates)
Fedde
-
- KVRAF
- 4071 posts since 4 Mar, 2008 from Near Pittsburgh
That all sounds good on paper. I'd prefer to smear my time on a nice piece of toast and worry about the ~1,000,001 other things that have a far greater impact on the sound of the final product. But that's just me.
-
- KVRist
- Topic Starter
- 54 posts since 17 Dec, 2009
Thanks for joining in the conversation Fedde and Buscemi!
Although the discussion has now moved away from getting SSD onto my Receptor (which still doesn't work yet for me, see next post), I am happy to engage in more complex comments in the meantime.
It is true that there are 1,000,001 things that impact the sound of the final product. I can also appreciate anyone that attempts to carefully consider the impact of sampling rate as one of the things in the final product.
I understand that this sort of thing has been a hot topic on the KVR forum, with many people offering sincere opinions and engaging in fierce debate. Respectfully, there is actually very little room for opinion and most of the debate has already been addressed by people much smarter than all of us (myself definitely included).
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
2) Sound does not get any worse by digitally converting 44.1k to any higher sampling rate
3) Using a higher sampling rate is to maximize computational efficiency, which allows for decreased latency/delay.
I can understand how it would be easy to conclude that because 96k is not an even multiple of 44.1k that there would be some sort of issues with up-sampling that would introduce distortion. However, one of the gigantic advantages of processing information digitally, is that many things are processed perfectly mathematically, including sample rate conversion (given that all sample rates are greater than twice the highest frequency). All reasonable algorithms for up-conversion include interpolation which allows for perfect reconstruction of the signal regardless of whether the new sample rate is a multiple or not.
It would actually be significantly more complicated to write an algorithm that introduces time smearing in order to some how reuse each and every sample. I would be interested in learning about an algorithm that does this if you have the time.
If anyone is interested in the mathematics behind most of this, I will be happy to point you in the direction of the people that have done work in this area. It is not simple, if you have never seen it before. It is not always simple, even for those of us who have been through it many times.
Eric
Although the discussion has now moved away from getting SSD onto my Receptor (which still doesn't work yet for me, see next post), I am happy to engage in more complex comments in the meantime.
It is true that there are 1,000,001 things that impact the sound of the final product. I can also appreciate anyone that attempts to carefully consider the impact of sampling rate as one of the things in the final product.
I understand that this sort of thing has been a hot topic on the KVR forum, with many people offering sincere opinions and engaging in fierce debate. Respectfully, there is actually very little room for opinion and most of the debate has already been addressed by people much smarter than all of us (myself definitely included).
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
2) Sound does not get any worse by digitally converting 44.1k to any higher sampling rate
3) Using a higher sampling rate is to maximize computational efficiency, which allows for decreased latency/delay.
I can understand how it would be easy to conclude that because 96k is not an even multiple of 44.1k that there would be some sort of issues with up-sampling that would introduce distortion. However, one of the gigantic advantages of processing information digitally, is that many things are processed perfectly mathematically, including sample rate conversion (given that all sample rates are greater than twice the highest frequency). All reasonable algorithms for up-conversion include interpolation which allows for perfect reconstruction of the signal regardless of whether the new sample rate is a multiple or not.
It would actually be significantly more complicated to write an algorithm that introduces time smearing in order to some how reuse each and every sample. I would be interested in learning about an algorithm that does this if you have the time.
If anyone is interested in the mathematics behind most of this, I will be happy to point you in the direction of the people that have done work in this area. It is not simple, if you have never seen it before. It is not always simple, even for those of us who have been through it many times.
Eric
-
- KVRist
- Topic Starter
- 54 posts since 17 Dec, 2009
So, SSD does not work on my Receptor yet. I have contacted Muse Support and they are been very responsive all afternoon (much appreciated), but I still can't get it to work. If anyone has any suggestions, feel free to jump in now!
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?
Eric Tarr
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?
Eric Tarr