When can we stop making 32-bit plugins?

[braj]

I seriously doubt anyone willing to spend 13k on a sample library is still using 32-bit.

yep. Or even $200 on any plugin.

[wagtunes]

I just listened to the 8Dio Adagio Strings. $499. Amazing sound. Specs are minimal. Runs in Kontakt. They sound just as good as EWQL. The solo strings especially sound excellent.

I'd still love to know on what systems these demos are made because I can't imagine 32 bit, 2 gig of RAM and an I3 can pull this off.

But yes, you have a point. Anybody spending this kind of money on sample libraries isn't using 32 bit. So I guess it makes my entire argument moot and irrelevant.

Well, don't I feel like an idiot.

Turning 60 has definitely fried my brain.

[braj]

Well, don't I feel like an idiot.

Turning 60 has definitely fried my brain.

You are definitely not an idiot, brother.

[ghettosynth]

I seriously doubt anyone willing to spend 13k on a sample library is still using 32-bit.

Right, and trying to argue for the necessity of 32 bit plugins from an OS limitation is a bit silly today. I can't remember when 4GB was enough memory for my main desktop machine, it's been years.

I just loaded one of my larger projects and it's not really that large. The sample clips alone means Reaper is using nearly 2GB of ram just to hold the project. With background processes running Win7 x64 consumes 4GB of ram with that one project loaded. Note, there isn't an orchestral library to be found on that project.

Just to be able to use more memory for all tasks involved forces most of us into using a 64 bit OS and, consequently, once we're there, it's a simplification to not have to deal with 32 bit plugins.

[aciddose]

The question is how is wags argument not off-topic?

Does it have anything to do with the authors of other plug-ins ceasing to distribute 32-bit versions? No.

How is it related?

[braj]

Lol, yeah, Wags was saying 32 vs 64 really does come down to sound quality in real world usage, ie. you can't use memory you don't have available, no matter how much it is possible for someone to make a plugin that dynamically loads only what you need when you need it, you still run into that 4GB limit if you are doing big projects. I ran into it on my somewhat small projects, I just checked, even streaming, Trillian uses like 1.5 GB for one multisampled instrument at high quality, if I want to lower the quality to work in 32 bits, I can, I did, and that's why I eventually went 64 bits, to get the best sound quality and most importantly stability by not running out of RAM. So it can affect sound quality. It wasn't off topic, but he got intellectually bullied anyway. Some people just want to show how big their pecker is apparently.

[ghettosynth]

The question is how is wags argument not off-topic?

Does it have anything to do with the authors of other plug-ins ceasing to distribute 32-bit versions? No.

How is it related?

It might have been a bit of an awkward point, but, there's something there. If you use sample libraries, and they don't have to be "Orchestral" sample libraries then the expectations are often that you have more than 4GB of RAM.

Here's one from Soniccouture that I have and use.

Windows 7 or higher (latest Service Pack, 32/64 Bit), Intel Core Duo or AMD AthlonTM 64 X2, 4 GB RAM (6 GB RAM recommended)
Mac: OS X 10.9 or higher, Intel Core 2 Duo, 4 GB RAM

Here's one from Waves that I have and use.

Mac
Memory
8 GB RAM
8 GB free disk space on the system drive

Windows
Memory
4 GB RAM
8 GB free disk space on the system drive

Ok, they'll work in a 32 bit system, but not well. The question is asking when will the market for 32 bit be small enough that there's no point in making them and the fact that sample libraries are getting larger and demanding more RAM IS evidence that people are moving on from 32 bit. Sure if you're not using any sample libraries this doesn't matter to you, but, when looking at the aggregate I would guess that most people are using some mix of sample based instruments and non sample based instruments.

So, we have:

Major DAWs are going 64 bit only.
Many sample libraries are de facto recommending 64 bit OSes.
Most users have other needs that drive a 64 bit OS install.
The Major OS players are moving towards 64 bit only.
Some plugins are only 64 bit.
64 bit has been out and stable for a number of years now.
It's generally accepted that mixed 32 bit and 64 bit plugin usage is less stable.

This is evidence that we are in a mature state with respect to 64 bit acceptance and usage and that the transition point where 32 bit isn't worth it for support reasons will trump 32 bit is worth it for sales. How close that is for you as a vendor is only something that you can decide.

But I don't see how his point, no matter how it was presented was off topic. It relates to acceptance and adoption of 64 bit and the related abandonment of 32 bit over time.

[aciddose]

Well it doesn't actually add anything though, and it is simply incorrect to say that generally speaking the memory available has a significant influence. Especially with plug-ins from the period which were designed while 1 gb was generally the peak memory available system-wide, so an individual plug-in using more than 128 megs was absolutely insane. (Bigger samplers typically did this during the 2000 - 2010 period.)

It just doesn't add anything beyond the simple observation that we're seeing a Gaussian distributed focus of platforms as is to be expected by the combination of many different source distributions which will almost always result in a skewed Gaussian.

Yes, today "most people" are using a 64-bit system. Wags argument is more an attempt to convince people using 32-bit systems to switch to 64-bit though, which is 100% off-topic.

Of course nobody will argue with wags on that point, but to broadly state that "quality is affected" is stupid and untrue, while begging-the-question is not a valid argument to begin with because it assumes the conclusion.

"If you want to use a modern 64-bit-only sampler library, you'll need to use a modern 64-bit system, therefore using a 32-bit system will limit you and prevent you from using 64-bit software unavailable on any other platform."

Uh... well obviously.

The exact inverse of the argument is "certain 32-bit-only software that can't operate correctly on 64-bit platforms without a bit-bridge ..." In fact certain software+hardware combinations exist which can't address more than 32-bit addresses which means such hardware (certain DSP cards) can't operate correctly on 64-bit systems at all without having control of how memory is physically allocated (not a capability of any current major operating systems or languages.)

A_SN's comments about technological plateaus are far more interesting: as 32-bit platform devices wear out, and assuming there is no "128-bit" or other such platform (foolish to assume, but acknowledging that) we should over time see the existing Gauss distribution "flatten" and become eventually a more uniform distribution with the vast majority of systems being the 64-bit platform.

This is entirely possible of course although also extremely unlikely. We're in my opinion far more likely to be moving toward distributed, multi-dimensional systems (memory, processing and bandwidth) rather than CPU-based systems. The Von Neumann architecture has near nowhere further to progress (also foolish, considering vacuum-based atomic scale transistor technologies) and this is almost entirely the reason we're in the "valley" we've been trapped in for the past near decade.

Still though the long tail of the distribution shows significant diminishing returns and even now we may be at the point where it no longer makes sense to limit new technologies to obsolete systems.

So I just don't see how that line of thinking adds anything on-topic to the discussion as opposed to nearly completely derailing the thread toward "32-bit vs. 64-bit" as is typical.

[ghettosynth]

Yeah, but, as interesting as that is, I'm only taking issue with your comment that Wag's point was off topic. I would argue that the speculation of system structure over the next few decades is every bit, if not more off topic. That really has little to do with where we are with respect to 32 bit having any market share of interest. I think that your assessment was a bit harsh.

[aciddose]

The fact that you can't load >4gb sample libraries on 32-bit systems never stopped anyone during the past 20 years before 64-bit systems existed, so why should it now?

Wags is essentially arguing that the "quality" of any library (past, present or future) can't possibly compete without more memory to load many gigs of unused samples all at once. I just don't see how that applies to the question of whether modern software should still be built/distributed for 32-bit systems.

It absolutely should except perhaps in the cases where functionality of the software absolutely requires that additional memory. As Wags found though, even for his touted "superior high-quality libraries" that isn't often true.

It's easy to make the argument in a 32-bit vs. 64-bit debate where the question is "Which system should I buy?", but as far as I'm aware you can't even buy a 32-bit system today without going hunting for a used one and regardless it would likely cost more than a far more powerful completely new 64-bit system.

So again, how does making the argument add anything at all? I don't think it does.

I only took issue with the bullshit statement that "quality is affected". It's simply untrue, period. It relies upon a fallacious argument, "begging the question".

[mutantdog]

Arguments for switching to 64-bit are just as relevant as the various arguments made for sticking with 32. I'm sure most people that have gone through the time-consuming process of re-installing everything will have had to reason the pros and cons to themselves, i know i did. When it came down to it, the freedom to use large sample-based instruments (should i wish to) outweighed the value of a few replaceable old SE/SM plugins.

[AnX]

When i was on WinXP, i had 0.5gig ram. Its was only a struggle right at the end. The reason i had to update to a new pc was i had no sse3. Im now on Win7 64bit with only 4gig ram. I dont use big rompler stuff.

[ghettosynth]

The fact that you can't load >4gb sample libraries on 32-bit systems never stopped anyone during the past 20 years before 64-bit systems existed, so why should it now?

That's not exactly correct, it's not about whether or not you can't load > 4GB library. I think that it's well understood, at least by the technically literate, that the size of the sample library is generally larger than the in-memory footprint. However, the reason that RAM specs increase as larger libraries become more commonplace is because vendors don't want to work with smaller amounts of RAM. I get your point but I don't agree that discussing trends in a topic that's asking about trends is off topic. That has nothing to do with the quality of any argument therein.

Komplete 5 (2008)

Mac OSX 10.4.x, G5 1.4 GHz or Intel Core Duo 1.66 GHz, 1 GB RAM.
Windows XP or Vista, Pentium or Athlon 1.4 GHz, 1 GB RAM.
4.5 GB free disc space/65 GB for complete installation.
DVD drive.

Komplete 9 (2013)

Windows 7 or Windows 8 (latest Service Pack, 32/64-bit), Mac OS X 10.7 or 10.8 (latest update) Intel Core 2 Duo or AMD Athlon 64 X2, 2GB RAM 8GB free disc space (90GB for complete installation), USB 2.0

Komplete 11 (2016)

4 GB RAM (6 GB recommended for large KONTAKT Instruments)
10 GB free disk space (122 GB for complete installation).

Those RAM increases are driven purely by sample libraries. Citing a 4GB minimum is rather pointless on any functional 4GB system. I'm not as convinced as you that large sample libraries always worked just fine on smaller systems. I suspect that 1GB minimum RAM spec drove a lot of support calls that drove a few returns and quite a few more RAM upgrades.

I think that the recommended specs are much closer to the true story and the state of the industry than any minimum spec. Here's a post from 2010 where a user is recommending 16 GB of RAM or more for VSL and is running 64bit Windows 7.

https://www.vsl.co.at/community/posts/m ... post177974

64 bit and large RAM configurations for symphonic libraries have been essentially SOP for the better part of a decade. Since vendors no longer have to make the same compromises that they use to have to make for 32 bit systems. So they are going to optimize for larger systems.

[fmr]

Well, how do you account for the difference in quality between a $5 hamburger and a $50 steakhouse steak?

That's a sort of arbitrary and subjective question isn't it? Do you have any examples of the same library running on both systems where there is a difference?

Well that's the problem. You can't load Vienna Strings on a 32 bit system. It won't work. It's why when I went with EWQL (I could not justify the price of Vienna) I had no choice but to go to a 64 bit system.

So no, I have no examples of a 64 bit library running on both systems because it can't be done.

What Vienna Strings are you talking about? There are MANY Vienna Strings. All run inside Vienna Instruments and Vienna Ensemble, and both run as 32-bit, as well as 64-bit. Of course, you may load more instruments in a 64-bit environment, but just the strings alone, I doubt they will not load in a 32-bit Vienna Ensemble or Vienna Instruments.

Here are the minimum system requirements for Vienna Ensemble:

PC Windows 7/8/10 (latest update, 32/64-bit), Intel Core 2 Duo or AMD Athlon 64 X2
Mac OS X 10.8 (latest update) or higher, Intel Core 2 Duo
2 GB RAM (4 GB recommended)
Working Gigabit connection between master and slave computer(s). Also works on a one-computer setup.
ViennaKey (Vienna Symphonic Library USB protection device) or other USB eLicenser (e.g., from Steinberg or Arturia)
eLicenser Control Center software (get the latest version from http://www.eLicenser.net)

[Mutant]

Unfortunately, I don't. But I'll concede this one because technically, according to these companies, their software runs on 32 bit.

I have no idea how given how many samples have to be loaded.

There is no music creation PC on the planet with as much RAM as these sample libraries take on the HDD.
The whole trick of the DFD is that these samples DO NOT have to be loaded.
If i remember correctly, only first few miliseconds of the sample is loaded into RAM.
Only as much as it will take for the hard disk (or preferably SSD) to load the rest when the sample player software detects that the sample is being played.