Massive X 1.6.1 update (September 2025)!

[SLiC]

Massive X is pretty good but there are lots of good alternatives
Kontakt however (for better or worse) is pretty much the industry standard for sample based stuff.
Reaktor is still IMHO one of the greatest software instruments ever made. Maschine is pretty great as well, so overall NI are hard to ignore.

[chk071]

i have interest in Massive X and i use Kontakt (as little as i can). I still hate it tho.

Then you have a problem. If you're interested in things you hate.

[Ploki]

Massive X is pretty good but there are lots of good alternatives
Kontakt however (for better or worse) is pretty much the industry standard for sample based stuff.
Reaktor is still IMHO one of the greatest software instruments ever made. Maschine is pretty great as well, so overall NI are hard to ignore.

I agree, but they use dated frameworks so their plugins look like they’re from 2005 on any hidpi screen and they’re slower to go apple silicon than f**king pace/ilok.
Then its the whole kontakt treating drives and ram like its 2002. 8k video editors can use 32gb of ram, but for two libs you need 128gb? Because kontakt is too archaic to make use of NVMe speeds? Ugh.

Also agree re: reaktor. All great stuff.

But KK with its wrapping is imo a bad concept. I dont use plugin wrappers.
Especially in the case of KK cause all my M1 native shit would work in rosetta

@chk071: i cant help if some libs are kontakt exclusive

[SLiC]

I absolutely agree about the GUIs (and I could list a ton of other stuff!) but apple silicon is still a very small % of users so I hope they spend their development time on cross platform stuff like the resizable and HiDPI GUIs and not M1 stuff (happy for everyone to get that as well at some point, but NI was as you said behind in many more general areas that affect a far larger user base than people who bought a new MAC in the last 6 months in the full knowledge that not all software may be supported immediately, or indeed ever!)

I can't say I agree about KK, the MK2 is the best controller keyboard I have owned (and I have had most of them over the years) and the 'wrapper' concept seems to be how they all work- NKS is by far (all UHE Stuff, AAS, Arturia etc) the best supported and makes software a bit more like hardware...there is a lot of room improvement, but I still haven't found anything better personally.

[EvilDragon]

Then its the whole kontakt treating drives and ram like its 2002. 8k video editors can use 32gb of ram, but for two libs you need 128gb? Because kontakt is too archaic to make use of NVMe speeds? Ugh.

Whatever are you talking about? You can definitely load a toooooooon of stuff in 32 gigs of RAM... All depends how you set the DFD buffer size globally. For which two libraries do you need 128 gigs of RAM, pray tell?

Kontakt definitely benefits from SSD speeds, but it doesn't utilize I/O queue depth (stays at QD1 all the time since that's how HDDs work). But even with QD1, you get a huge huge performance boost over the regular HDDs, and especially random seek time is so much better (and DFD benefits a lot from that).

[Ploki]

@SLiC:
Yeah KK (as i said gf has S61 mk3) in general is great, probably the best piece of midi hardware i touched.
And yes the wrapper thing is a broad observation not specific to KK, I don't like the concept, not NI's specific implementation. It's likely one of the better implementations, but since most my instruments are already native M1, if i were tied to NI's wrapper i'd still need to run everything rosetta. It just irks me to have stuff i used tied to a wrapper, it's a nagging feeling i can't get over.

re: M1, i think the new MacBooks will put more pressure on devs. They're all over the place and their audio performance is really good. It's been more like a year and a half than 6 months (apple shipped dev kits early summer 2020).
I get that being stuck on old framework is a problem, but it's been a problem older than M1 native and if they fixed that, they wouldn't have the M1 problem now.

Whatever are you talking about? You can definitely load a toooooooon of stuff in 32 gigs of RAM... All depends how you set the DFD buffer size globally. For which two libraries do you need 128 gigs of RAM, pray tell?

Kontakt definitely benefits from SSD speeds, but it doesn't utilize I/O queue depth (stays at QD1 all the time since that's how HDDs work). But even with QD1, you get a huge huge performance boost over the regular HDDs, and especially random seek time is so much better (and DFD benefits a lot from that).

Yes exactly. With NVMe drive IOPS you could run kontakt directly from disk without even touching RAM, if it weren't build for machines from 2010.
I'm being obtuse and generalising, but the general consensus on orchestration groups and forums is "get M1 Max with at least 64GB RAM" and people build 128GB rigs for kontakt.
If you ask me, it's absolutely bizarre, considering you can get a 2TB Samsung 980 PRO with 7000mb/s throughput which is what RAM speed was some odd 10 years ago.

The point is you shouldn't even need 32GB of RAM to run some stupid samples. I could run DFD with 12kb buffer from 10000rpm raptors a decade ago, and wow i still can from a 3gb/s NVMe? Amazing.

[EvilDragon]

7000 MB/s throughput is something that does NOT apply to direct from disk streaming. That's sequential reads, which are very rarely happening in DFD scenario. You need to look at 4k random read number, not total IOPS.

[Ploki]

7000 MB/s throughput is something that does NOT apply to direct from disk streaming. That's sequential reads, which are very rarely happening in DFD scenario. You need to look at 4k random read number, not total IOPS.

Average 20000 IOPS (as good as SATA3 sequential), peak random 1million iops?
https://www.tomshardware.com/reviews/sa ... ssd-review

DDR2 had equivalent of ~60000 IOPS.

Do you really need latency of RAM for reading some samples? You have a full buffer size of time to seek or samples.
I really don't think sample playback is at all optimised for modern systems, but i might be wrong.

[EvilDragon]

There's a bunch of other things to do besides reading the samples in order to produce that one audio buffer (like doing the actual DSP and so on). And as fast as it is, NVMe random access time is still orders of magnitude slower than RAM, and this does cut into the time needed to produce the audio buffer - so it's prudent to make the sample reading as fast as possible. So yes, even with superfast NVMe, utilizing RAM for preloading initial chunks of samples is still gonna be more efficient and also, more importantly, allow you to stream more voices under less stress.

[DJ Warmonger]

I don't get what's wrong with your RAM usage. While Kontakt is certainly outdated, it also means it ran on legacy rigs and thus has low requirements. Many Kontakt libraries were built when computers had ~1 GB of RAM in total or less and you had to stream stuff from HDD anyway.

Now, I was sure I wouldn't ever touch the capacity of 16 GB in my PC no matter how many instruments, but recently this happened due to... Arturia Pigments 3. Exactly 500 MB per instance. For a synth with default preset, with no samples loaded. Now this is a modern tech

[EvilDragon]

Omnisphere is pretty much the same. 500ish MB per instance with init patch (single saw).

[Ploki]

There's a bunch of other things to do besides reading the samples in order to produce that one audio buffer (like doing the actual DSP and so on). And as fast as it is, NVMe random access time is still orders of magnitude slower than RAM, and this does cut into the time needed to produce the audio buffer - so it's prudent to make the sample reading as fast as possible. So yes, even with superfast NVMe, utilizing RAM for preloading initial chunks of samples is still gonna be more efficient and also, more importantly, allow you to stream more voices under less stress.

But anything that isnt live input could easily be streamed from nvme. its not like you can play 500 notes live on a keyboard.

I just dont think its efficient at all and that gynormous orchestral rigs are that due to sheer inefficiency of software and nothing else

[EvilDragon]

You cannot play 500 notes live, but you can certainly have more than that many VOICES going on at once. Stereo sample? Two voices. 3x velocity crossfade? Triple the voice count. Multiple microphones? Multiply the voice count. Sustain pedal? Etc etc etc.

You can easily play 2000+ voices live this way. So yes, preload to RAM is extremely important. Most composers with those giant orchestral rigs actually do play their stuff in rather than click around the piano roll.

(And media composers had giant rigs even going back to pre-softsampler era, with racks filled with all sorts of samplers, so no their rigs are not so big because of software inefficiencies, they are like that out of necessity.)

[Ploki]

Yeah its played back but you can playback with a larger buffer = more seek time leeway.
Like logic plays every track except live input at 1024 buffer.
Granted that would require some DAW side flags, but still, it could be immensely optimised

[EvilDragon]

That doesn't apply when you record your parts in realtime and you have a big ensemble going that would need those 2k voices and so on. You need lowest latency possible then, so no you cannot do this without RAM preload.


What Logic is doing with double buffer does help but is not the end all be all bandaid.