When can we stop making 32-bit plugins?

[A_SN]

software becomes obsolete in moments anyway

100% wrong and it will be more and more obviously wrong as time goes on. What so many people fail to realise is that a few years ago (at least 10), we've entered a period of maturity for desktop software (and desktop computers in general), in which changes aren't so dramatic anymore.

The thing about periods of maturity for a domain of technology is that they happen much sooner than anyone expects, and you don't realise you were in them until decades later. For instance in the 1960s if you took a Boeing jet plane to Honolulu you might have been amazed by the recent progress done by the aviation industry, and reasonably extrapolate that by the year 2000 we'd have supersonic or orbital planes that would take you anywhere in the world in an hour or less, or even jetpacks and flying cars. Of course 50 years later you would have realised that actually the jet planes haven't changed much since then, and therefore that the technology was already mature. The same is true for a lot of technologies that had a crazy few decades then only slow evolutionary incremental change, the telegraph, the telephone, pistols, cars, planes, television, records, nuclear power plants and so on.

So actually now without realising we might very well be writing code or at least algorithms that will still be actively used in 50 years (with some adaptations, of course), and standards (like Unicode/UTF-8 for text, this thing is built to last) that will still be into use in 200! We don't need to redo everything over and over again every 5 years, and we won't!

after the sales disappear

It's actually not a real thing, people think it is but it's not, it's all a function of how much effort you put into selling it. The sales don't inexorably disappear, you just let it die. You can sell the same thing for a decade, and I should know, I'm getting close to 9 years with one of them.

[highkoo]

There is some analgoy to Excel;

A huge percentage of users only use the most very basic level of functionality.
Ten upgrades over a decade that enable previoulsy impossible functions to some users are literally meaningless to a huge amount of the userbase.
Many users are, by chance, using the 'lastest technology', but were they not, they would very likely not notice.

[A_SN]

There is some analgoy to Excel;

A huge percentage of users only use the most very basic level of functionality.
Ten upgrades over a decade that enable previoulsy impossible functions to some users are literally meaningless to a huge amount of the userbase.
Many users are, by chance, using the 'lastest technology', but were they not, they would very likely not notice.

Very good point, Excel '97 would still work fine for most users of today (well, except for the compatibility issues), as would Photoshop from 15-20 years ago, 3ds Max and other such 3D programs were quite advanced by the year 1999, and so on. So the way I see it there are many many things that we can create with software that we can barely fathom now, but many of the things that have already been done are about as good as they're gonna get. So when you make a spreadsheet program, it might well last for many decades without too many changes. And because people now have decades-old habits, there's even more reason for certain things to remain the same.

Besides, many people want VSTs that are just like old hardware, why in the future wouldn't people want plugins that are just like old VSTs? That's why plugins shouldn't be left to die, we should take care of what we created, when it's actually so easy to carry algorithms through the decades.

[SeeingInMidi]

In terms of the 32/64 bit argument, I don't think people will feel nostalgic about the "32-bit sound" because there isn't such thing really. Old samplers and vinyl have a personality that people can actually hear and feel nostalgic about.

We are discussing 32-bit/64-bit "COMPUTATION". It has nothing to do with the sound, just with the way Operating Systems and programs work.

32-bit vs 64-bit AUDIO is something different. You usually have nowadays programs working with audio internally in 32-bit float, while working as 64-bit applications in a 64-bit Operating System.

You misunderstood my post, i wasn't referring to bit depth... which is why I said there isn't a sonic difrerence 32-bit and 64-bit.

[wagtunes]

There is an indirect effect on sound between 32 and 64 bit OS if you're using an orchestral library, especially in regard to the strings.

In order to get the most faithful emulation of a string section, the number of samples and articulations that have to be loaded far exceed the max RAM that can be used on 32 bit systems. That's why the best string libraries are all 64 bit.

So, if you're on a 32 bit machine and need to do an orchestral score, the quality of the sound is going to be inferior to the same score rendered on a 64 bit system with a better library. There is no way around this. And even at that, not every 64 bit string library sounds amazing. But I've yet to hear a 32 bit library sound anywhere near convincing.

Like it or not, 32 bit OS is limiting as far as what you can do depending on your requirements. It's the reason why I decided to go with a 64 bit machine because I knew I wanted to do orchestral work and all the top libraries required 64 bit.

Doesn't mean you can't still do orchestral work on a 32 bit machine.

It's just not going to sound as good.

[Mutant]

There is no way around this.

Actually...
DFD

[wagtunes]

There is no way around this.

Actually...
DFD

And what's DFD?

[aciddose]

Technically it is entirely possible to stream from disk as well as dynamically load/unload components based upon probability of use. For example the lowest and highest notes will almost never be used, and that can significantly reduce the total number of samples needed. There is no sane reason to load 100 variations of a sample when that note is only played 12 times in a render.

The real reason is simple: managing with limited memory is a lot of extra work. You can't expect the authors of VST plug-ins (a tiny niche within a tiny niche) to be highly specialized in databases and memory management. (Or capable even above the level of "total dumb-ass".) If writing a plug-in required hiring a highly capable engineer $100k-200k to write and maintain algorithms for memory management, the plug-ins simply wouldn't exist.

What you can expect is for them to call a function like "load all samples in the universe EVER()" which has a super simple loop like "for (i = 0; i < 9billion; i++) { load sample(i); }" and leave it entirely to the system to handle memory management. When there isn't enough memory you're lucky to get "sorry, not enough memory" followed by a crash or silent output.

Then you can expect the system requirements to say "don't have more than 64 gigs of memory? sorry pal!"

[wagtunes]

Technically it is entirely possible to stream from disk as well as dynamically load/unload components based upon probability of use. For example the lowest and highest notes will almost never be used, and that can significantly reduce the total number of samples needed.

The real reason is simple: managing with limited memory is a lot of extra work. You can't expect the authors of VST plug-ins (a tiny niche within a tiny niche) to be highly specialized in databases and memory management. (Or capable even above the level of "total dumbass".)

What you can expect is for them to call a function like "load all samples in the universe EVER()" which has a super simple loop like "for (i = 0; i < 9billion; i++) { load sample(i); }" and leave it entirely to the system to handle memory management. When there isn't enough memory you're lucky to get "sorry, not enough memory" followed by a crash or silent output.

Then you can expect the system requirements to say "don't have more than 64 gigs of memory? sorry pal!"

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.

[aciddose]

Nobody is going to argue with you.

It is important to recognize that what you're calling "an inferior library" is just expanded in your implied "superior" library and is technically no different at all. The only thing different between them is that one is running on a superior 64-bit system.

Give credit where credit is due.

[wagtunes]

Nobody is going to argue with you.

It is important to recognize that what you're calling "an inferior library" is just expanded in your implied "superior" library and is technically no different at all. The only thing different between them is that one is running on a superior 64-bit system.

Give credit where credit is due.

Then how do you account for the difference in sound quality between Sonnovox and Vienna?

[aciddose]

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?

[wagtunes]

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.

[aciddose]

No, you are asserting that it "can't be done", but that's 100% bullshit because you honestly have no idea whether it can or not.

What you mean to say is that you are unaware of "it" (which you can't define) being "done" (also undefined.)

[wagtunes]

No, you are asserting that it "can't be done", but that's 100% bullshit because you honestly have no idea whether it can or not.

What you mean to say is that you are unaware of "it" (which you can't define) being "done" (also undefined.)

If the developer of the software specifically says in the specs "Minimum Requirements: Windows 7 64 Bit" I tend to take him at his word. I'd like to think that he'd know better than anybody else whether his software can run on a 32 bit machine.

And logically, it makes no sense to tell people that they have to have a 64 bit OS to run the software. That cuts down on sales. If 32 bit users can run the software, that translates to more sales.

So why say it can't run on a 32 bit OS if it can?