Are you still using 32-bit plugins on PC?

[EnGee]

Maybe a good compromise is to offer 32bit version but without a support, so those that use only 32bit software are not ignored completely.

[xtp]

I am still using Cubase SX3 [32bit 2005] running on Win 7, 64bit.

I am yet to find a reason to change, the sotware installed does everything I need it to do, in the same way it did back in 2005.

EDIT: just reading through this thread, and please note I have no opinion whether 32bit is still supported or not — but I do have a question — I have never written code for a plugin, in fact I have not written any code for about 15 years, and never for 64bit, but if any dev's read this, I am curious, as to what is involved in compiling out to 64bit, as compared to 32bit, from a technical perspective as opposed to an emotional perspective.

[FigBug]

EDIT: just reading through this thread, and please note I have no opinion whether 32bit is still supported or not — but I do have a question — I have never written code for a plugin, in fact I have not written any code for about 15 years, and never for 64bit, but if any dev's read this, I am curious, as to what is involved in compiling out to 64bit, as compared to 32bit, from a technical perspective as opposed to an emotional perspective.

If your code is well written, porting from 32 bit to 64 bit should be as simple as changing some compiler settings and recompiling. This assumes you've written all the code yourself, and you aren't relying on some 3rd party library that doesn't have a 64 bit version. (Then you're out of luck).

If your code isn't well written, and a lot of it from the 32 bit days isn't, then you can have some issues. The biggest issue is file formats. A lot of devs back in the day would define a big struct will all their preset variables and just write the whole block of memory to the disk. Converting to 64 bit the alignment and sizes of the variables change and you can no longer read the data files. (There are ways you can work around this but it's time consuming)

The other issue is audio devs do a lots of hacks in their code in the name of performance. Make assumptions, assume pointers and ints will always be the same size. Just copy one type of variable into another because it 'just works'. Then when they switch to 64 bit it all breaks.

Going from 64 bit to 32 bit can be harder, because some of the techniques just change. On Windows 32 bit your DAW and plugins have a total of 2 GB of memory to work with. This pretty much means unless they are small, you can't load all your samples into memory. So you need to build in some sort of streaming sample support.

In 64 bit, even if you don't have that much memory installed, your virtual address space is huge. You can load all your samples into 'memory' and and the OS will swap them into memory as needed. You just need to touch the memory a few milliseconds before you need it, the OS will fetch the data and you can play without stuttering. It performs so much better and is so much simpler than the old way.

Wavetables may also use a huge amount of memory pre generating tables for almost every note.

So a modern plugin, written assuming it can access a large amount of memory probably just won't work on 32 bit.

A plugin the started as 32 bit can probably keep going as 32 and 64 bit without much effort.

I've dropped macOS 32 bit. The latest Xcode can no longer compile 32 bit code. I'm not keeping an old version of macOS and Xcode around just to make 32 bit builds.

On Windows, that latest Visual Studio can still compile 32 bit code (but not for XP, so I've dropped XP support). It does double my build times, but that's not too big an issue for now.

I'll continue doing 32 bit builds as long as people use them and I can build them with that latest tools. Once I'm required to use old tools or language versions to support 32 bit on Windows, I'll drop it.

[FigBug]

Maybe a good compromise is to offer 32bit version but without a support, so those that use only 32bit software are not ignored completely.

This really doesn't fly. If customers buy something they expect it work.

[Freaqpeak]

I have so many 32 bit plugs running that have no alternative in 64 bit.
So I will still using Cubase 8.5 in the future although I would love to have Cubase 10.
I hope that jbridge will a new versions so that it would be possible to run it with Cubase 10.
I wonder that nobody developed such a thing as jbridge.

What? I use Cubase 10.5 with jBridge v1.75, works perfectly... Where did you get the impression that jBridge does not work with Cubase 10.x?

[EnGee]

Maybe a good compromise is to offer 32bit version but without a support, so those that use only 32bit software are not ignored completely.

This really doesn't fly. If customers buy something they expect it work.

What?!
Like I suggested a non-working version

[FigBug]

Maybe a good compromise is to offer 32bit version but without a support, so those that use only 32bit software are not ignored completely.

This really doesn't fly. If customers buy something they expect it work.

What?!
Like I suggested a non-working version

Well, if you want it to work, then it needs to supported and the bugs fixed. 'Unsupported and works' isn't an option. Either it's unsupported and eventually breaks or supported and works.

[xtp]

. . .

If your code is well written . . .

Cheers for the reply.

I guess it is a bit like the days of change when 32bit came in, and the differences the flat memory model introduced over segmentation.

[EnGee]

Maybe a good compromise is to offer 32bit version but without a support, so those that use only 32bit software are not ignored completely.

This really doesn't fly. If customers buy something they expect it work.

What?!
Like I suggested a non-working version

Well, if you want it to work, then it needs to supported and the bugs fixed. 'Unsupported and works' isn't an option. Either it's unsupported and eventually breaks or supported and works.

But most of the 32bit are either not supported or discontinued (abandoned). At least the new ones will be tested currently on new systems with current DAWs.
Or, it can be supported but only on current DAWs and OSes, for example Bitwig/Windows 10 or Reaper 6 32bit ... etc. Not on every DAW and OS since year 2000! That's crazy!

[synaesthesia]

The only 32-bit synth I miss using is SQ8L. Special little thing that.

[Ingonator]

The only 32-bit synth I miss using is SQ8L. Special little thing that.

SQ8L is working nicely here in Live 10 and Cubase Pro 9.5 (both are 64-bit only hosts) using jBridge.
I only have a few 32-bit plugins i currently use with jBridge and the most used one of those is SQ8L.

[synaesthesia]

The only 32-bit synth I miss using is SQ8L. Special little thing that.

SQ8L is working nicely here in Live 10 and Cubase Pro 9.5 (both are 64-bit only hosts) using jBridge.
I only have a few 32-bit plugins i currently use with jBridge and the most used one of those is SQ8L.

jBridge doesn't appear to work anymore in Cubase since I upgraded to 10, sadly. Not for me at least.

[rasmusklump]

Jbridge works perfectly in Cubase 10 and Cubase 10.5

[jamcat]

The only argument those of us who no longer use 32 bit plugins can make is that any time spent on them is time not spent on 64 bit versions, updates, upgrades etc.

I'm not even sure that's a valid argument because who knows how much extra work maintaining and supported 32 bit versions really is and if they're bringing in enough revenue to make it worthwhile again why not.

My gut feeling is that 32 bit plugins are more trouble than they're worth to small developers but only they would know for sure. The fact this Poll was started might be a good indication....

You are exactly right. Testing, maintenance, and support take up the lion's share of resources for a well supported software. Each format/platform that is supported increases the necessary man hours. All developers have finite resources, particularly audio software developers.

Those finite resources must be divided across all of the tasks. Unless it is a very small developer (one-man operation) the development team and the testing/support team are not going to be the same people. Testing takes the most time, and when the testing team has to test 10 different versions of a plugin instead of 5 different versions, this means either customers have to wait twice as long for an update, or they get software that is only half-tested.

You will recognize both scenarios from your experiences with your audio software. All developers make this choice, and it is in large part due to the high number of formats and platforms that need to be tested for every update.

I am a very big proponent for stripping down supported formats for this reason. Developers should only be supporting 64-bit VST3, AU and AAX on OSX and Windows. That is still 5 formats right there. It's past time to cut VST2.4 and 32-bit in all forms loose.

Someone who is not going to put in the money to upgrade their computer and/or DAW to something 64-bit from the past decade is not going to put money into new plugins to help keep your software company afloat.

Basically sharing the exact sentiment! Not so keen on the “VST3 only” thing, but that’s basically a force of habit on my part, paired with some bad experiences with VST3 back in the early days. I even would be perfectly willing to change everything to VST3 only if I knew that would reduce some workload for the devs. Well, native instruments are the ones which have to give me VST3 version first of course!
Plugins from other devs should be cool, since made sure everything is future proof when I switched back from Mac to pc in 2013/14.

I understand the impulse to cling to VST2 as a security blanket. But keep in mind that support and maintenance for VST2 was discontinued in 2013, and the VST3 SDK no longer ships with a VST2.4 subset as of October 2018 (Steinberg gave developers a generous 5 year window to switch over to VST3). Developers who are still developing VST2 plugins are using an outdated VST SDK. Over time, this will present a problem for developers still using that last SDK with 2.4 support as VST3 continues to diverge from it. The sooner they cut the cord, the better.

[synaesthesia]

Jbridge works perfectly in Cubase 10 and Cubase 10.5

Thanks! That solved it!

But, seriously, all 32-bit plugs get blacklisted for me, with no bridging occurring at all.