When can we stop making 32-bit plugins?

[aciddose]

Well "it", if we're defining "it" as being a particular piece of low quality software lacking that particular functionality (efficient memory management) then no, a more efficient "superior" implementation was likely not written for that particular bit of software.

That doesn't mean it couldn't be written and work fine: although nobody sane would attempt to do so for obsolete hardware today.

It's not an issue of "mostly correct", it's an issue of the difference between what is technically correct or not. To state that it isn't possible is to overlook the fact that all of this software is inherently very low quality and lacks such advanced functionality due to cost constraints.

So I would not have been bothered if you'd phrased things a little differently, like so:

"The authors of modern sample libraries lack the capability/expertise to implement memory management technologies enabling their libraries to be used on 32-bit systems with memory constraints, so only 64-bit systems are supported in the particular cases that I am aware of, for specific libraries."

[wagtunes]

Well "it", if we're defining "it" as being a particular piece of low quality software lacking that particular functionality (efficient memory management) then no, a more efficient "superior" implementation was likely not written for that particular bit of software.

That doesn't mean it couldn't be written and work fine: although nobody sane would attempt to do so for obsolete hardware today.

It's not an issue of "mostly correct", it's an issue of the difference between what is technically correct or not. To state that it isn't possible is to overlook the fact that all of this software is inherently very low quality and lacks such advanced functionality due to cost constraints.

So I would not have been bothered if you'd phrased things a little differently, like so:

"The authors of modern sample libraries lack the expertise to implement memory management technologies enabling their libraries to be used on 32-bit systems with memory constraints, so only 64-bit systems are supported in the particular cases that I am aware of, for specific libraries."

Okay, given what you just said (your OWN words) it doesn't change the underlying fact as far as what is "available" on the market today and the point of my post.

If you have a 32 bit machine and want to get a string library, it is not going to sound as good as the string library you COULD get if you had a 64 bit machine. I don't care if it's out of what's technically possible or laziness. The bottom line is the sound quality of what you're going to be working with, in regard to string libraries (they are the most difficult to reproduce) is going to suffer if using a 32 bit machine given the reality of the consumer world that we live in.

Better?

Sheesh. Semantic Police.

[aciddose]

That's simply untrue. You're focused on concrete, specific, existing libraries that don't have memory management capabilities.

Tomorrow the "next big thing" library could come out with such an implementation and work fine on older 32-bit hardware with absolutely no difference. The biggest difference would be it would also save on processing and memory use for 64-bit systems as well as load times and other important factors.

I myself have written plenty of code to deal in multi-gigabyte data sets (16 gig files anyone?) that I had to optimize to only operate on smaller chunks, not to save memory (this system has 64 gigs available) but to make it use a reasonable amount of memory as is actually required to get the job done without wasting it.

Those huge sample libraries you're referring to are amazing examples of gluttony and excess and I wouldn't be surprised if your home is several degrees hotter while running them and your lights flicker and brown-out.

Demanding better from the authors wouldn't hurt, really. It at least makes sense to acknowledge the real source of the issue which in this case is not solely the memory constraints of 32-bit systems.

[wagtunes]

That's simply untrue. You're focused on concrete, specific, existing libraries that don't have memory management capabilities.

Tomorrow the "next big thing" library could come out with such an implementation and work fine on older 32-bit hardware with absolutely no difference. The biggest difference would be it would also save on processing and memory use for 64-bit systems as well as load times and other important factors.

I myself have written plenty of code to deal in multi-gigabyte data sets (16 gig files anyone?) that I had to optimize to only operate on smaller chunks, not to save memory (this system has 64 gigs available) but to make it use a reasonable amount of memory as is actually required to get the job done without wasting it.

Those huge sample libraries you're referring to are amazing examples of gluttony and excess and I wouldn't be surprised if your home is several degrees hotter while running them and your lights flicker and brown-out.

Demanding better from the authors wouldn't hurt, really. It at least makes sense to acknowledge the real source of the issue which in this case is not solely the memory constraints of 32-bit systems.

Yes, I am focused on existing libraries. Until somebody comes out with this amazing 32 bit system that you claim is more than possible, it is the only thing I can focus on. That is the current reality as far as what exists in regard to string libraries. If I'm wrong, show me the string library that currently exists on 32 bit that can compete with 64 bit libraries as far as quality of sound.

People like you absolutely drive me crazy.

[A_SN]

If 32 bit users can run the software, that translates to more sales.

The whole point of this thread is that this is debatable, probably doesn't anymore.

And aciddose is right, we could squeeze a lot more within the constraints of 32-bit development, but people don't necessarily have the skills or the will to do it right, and that's the point of this thread too, we shouldn't have to be limited by obsolete limitations. Although it really doesn't hurt to be smart and not waste gigabytes of RAM pointlessly, but it's always how it is isn't it, give developers more resources and they'll find ways to waste it all away. Let's be honest here, we plugin developers might be good, but we're not the best and brightest either, more than anything you need to be a jack of all trades because you're alone or almost alone making entire products, you don't necessarily get to devise advanced ways of handling everything, you go with what works. So there's a big gap between what we actually do and what could be.

[wagtunes]

If 32 bit users can run the software, that translates to more sales.

The whole point of this thread is that this is debatable, probably doesn't anymore.

And aciddose is right, we could squeeze a lot more within the constraints of 32-bit development, but people don't necessarily have the skills or the will to do it right, and that's the point of this thread too, we shouldn't have to be limited by obsolete limitations. Although it really doesn't hurt to be smart and not waste gigabytes of RAM pointlessly, but it's always how it is isn't it, give developers more resources and they'll find ways to waste it all away. Let's be honest here, we plugin developers might be good, but we're not the best and brightest either, more than anything you need to be a jack of all trades because you're alone or almost alone making entire products, you don't necessarily get to devise advanced ways of handling everything, you go with what works. So there's a big gap between what we actually do and what could be.

Great, and I'm not even arguing that. It is quite possible we could do amazing things with 32 bit. But the reality, at least as far as large sample libraries, is we don't. And that means if I have a 32 bit machine I can't take advantage of the "currently" best sounding string libraries.

[A_SN]

And that means if I have a 32 bit machine I can't take advantage of the "currently" best sounding string libraries.

In practical terms, yes.

[aciddose]

The problem is simply this statement is wholly incorrect:

The bottom line is the sound quality of what you're going to be working with, in regard to string libraries (they are the most difficult to reproduce) is going to suffer if using a 32 bit machine

For this to be correct relies on the assumption that the person we're talking about is "wagtunes", while you may be surprised to find out but believe it or not, most people are not "wagtunes". Not everyone is using the favorite "must have" library that "wagtunes" uses.

In fact there are plenty of people out there which this argument doesn't make the least bit of sense as they'll never be interested in a cinematic library. So if we do away with that assumption (which was stupid to begin with) we end up with this: "The bottom line is the sound quality of what you're going to be working with, ... is going to suffer if using a 32 bit machine".

That's just a stupid statement to make, period, and it doesn't prove or demonstrate anything of any significance at all.



Regarding memory constraints, in fact:

Linux 4.14
1. Prominent features
1.1. Bigger memory limits

Original x86-64 was limited by 4-level paging to 256 TiB of virtual address space and 64 TiB of physical address space. People are already bumping into this limit: some vendors offers servers with 64 TiB of memory today. To overcome the limitation upcoming hardware will introduce support for 5-level paging. It is a straight-forward extension of the current page table structures adding one more layer of translation. It bumps the limits to 128 PiB of virtual address space and 4 PiB of physical address space. This "ought to be enough for anybody" .

On x86, 5-level paging enables 56-bit userspace virtual address space. Not all user space is ready to handle wide addresses. It's known that at least some JIT compilers use higher bits in pointers. It collides with valid pointers with 5-level paging and leads to crashes. To mitigate this, the Linux kernel will not allocate virtual address space above 47-bit by default. Userspace can ask for allocation from full address space by specifying hint address above 47-bits.

"This "ought to be enough for anybody" ."

[wagtunes]

Okay, this is the last I'm saying on this and then I'm done arguing with you.

My statement, if you actually took the time to READ it, specifically limited my claim to orchestral libraries. I know that everything else as far as 32 or 64 bit doesn't make a damn bit of difference.

If you are a customer for an orchestral library of high quality, you MUST have a 64 bit machine because there are no high quality libraries that currently run on 32 bit machines.

Until somebody shows me the 32 bit library that is of high quality that can run on a 32 bit machine, that is the current reality.

And with that, I am done with this crap.

[aciddose]

Exactly, so your statement was "X doesn't have a 32-bit version."

I was pointing out that your conclusion "therefore: C" is incorrect because you set up this extremely limited context "X" wherein "C" is true because "X = C", but that doesn't actually prove of demonstrate anything of actual value.

All you've stated is "X = C", "X doesn't have a 32-bit version."

That's called "begging the question".

[Mutant]

So what you're saying is while DFD makes it possible to run a high quality library on a 32 bit system, nobody has done it yet.

So in other words, what I've said is still essentially true. If you're running a 32 bit system, you're restricted to an inferior quality library.

Actually...

System Requirements

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
4 GB RAM (8 GB recommended)
VIENNA KEY (Vienna Symphonic Library USB protection device) or other USB eLicenser (e.g., from Steinberg or Arturia)
467.9 GB free hard drive space

[mutantdog]

I know its fun arguing with Wags but I'm gonna have to back him up here. Irrespective of whether it is in principle possible to create a large sample-based orchestral instrument that works in 32-bit, the reality is that as a consumer the availability of such products is, at best, limited.

As far as i can tell, the main argument for sticking with 32-bit is to be able to use old freeware instruments and effects while the main argument for using 64-bit is to be able to use newer high-end sample-based instruments. Whichever you consider a priority is entirely subjective, but the results of the poll suggest most people choose the latter.

[wagtunes]

So what you're saying is while DFD makes it possible to run a high quality library on a 32 bit system, nobody has done it yet.

So in other words, what I've said is still essentially true. If you're running a 32 bit system, you're restricted to an inferior quality library.

Actually...

System Requirements

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
4 GB RAM (8 GB recommended)
VIENNA KEY (Vienna Symphonic Library USB protection device) or other USB eLicenser (e.g., from Steinberg or Arturia)
467.9 GB free hard drive space

This doesn't tell the whole story. Look at the recommended specs.

Minimal specs will get you minimal performance. How minimal? No way to know until I tested it out on a 32 bit machine, which I don't have.

I seriously doubt the sound demos I'm listening to were done on a 32 bit machine with 2 gig of RAM.

And forget that the entire Vienna library costs 13,000 euro compared to the entire EWQL collection which costs a fraction of that.

So yeah, technically a good quality library can run on a 32 bit machine with 2 gig of RAM, according to their minimum specs.

But let's see how many instances you can run and how well even one instance runs.

Again, not telling the whole story here.

[wagtunes]

I just did some research. Seems EWQL is the only library requiring 64 bit.

I wish I had the money and the time to test out all these libraries that supposedly run fine on 32 bit to see just how good they really are under those conditions.

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.

[mutantdog]

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