oh, nice. I didn't know that. But I use it in 32 bits plugins mainly.
here some plugins: linplug delta 3, psychic modulation phonec, t-pulse, pro53, A1, superwave plugins, trilogy, ivory, vaz, morgana, hv formant, cheeniguqin, manx, ignite, arabic world strings, deep one, nitroflex, smartelectronix plugs, edirol orchestra, trancerone, ravernator, nts labs, universal piper, virtual guitarist, wok, bitsonic, badass, jp6k, bagpipes, vanguard, stylus rmx, iz spectron, pre-zynaptiq morpher, imposcar, minimonsta, freqmod, hematohm, mobilohm, ohmboyz, ohmygod, predatohm, quadfrofmage, symptohm melohman, wavearts suite, maxwell limiter, some old plugs, some free and casual plugs and a lot of other nice plugins - there so much plugins, so little time...
enough for you Dan? oh, and ofcourse nexus and sonnox
there some vintage spirit in 32 bits, you know

 

Last edited: Dec 13, 2017

x64 for sure.

there is so much garbage in the list like

like really, are you serious?

So i have no idea what you are smoking, but get some right stuff and check/think twice before posting something. Second time you're trying to provide wrong information.

Or save lil bit and finally get the inflator.

 

man I'm not such expert as you, so plzzz be gentle.

lambo after kids is garbage too. oh, sorry I forgot only cubase is nice or maybe something else?

lol, second time you're trying to accomplish your wrong decision, ever more, everytime...

no, thanks

oh, I see trilogy and ivory are 32 bits only. but don't mind, it's garbage

 

but seriously what is garbage in this list? You wanted list - I've got it for you.
and how your subjective sense of quality is related to cubase, vst3, 64-bits and all this marketing shit around it?

 

Last edited: Dec 13, 2017

As far as i know
those developers which are working and active; they have x64 plugins,
even some of those left the x32 and just working on x64 plugins!

 

yes, fully agree with you! 64-bit floating point engine has been even used by DICE in roughly 2006 in their frostbite engine

 

wrong, if you write code you will do it for x86-64, cuz this is standart de facto

not quite right. there a lot free modern vsts in 32 bits, there just no need for 64 bits

 

Thank you ia for little info,
But check the Steinberg, as i see new version of Cubase is x64 engine and it means it doesn't support x32 bit plugins!
am i wrong?

 

Yes there is a need for 64-bits plugins. How else could they cram 50 or more MB of graphics into a plugin??

Seriously speaking, we needed 64-bits OS badly for browsers, video editing, photo editing... and Microsoft Excel. Sorry, couldn't help it. But regarding audio indeed only to be able to deal with huge sample libraries which became outrageously big and impossible to fit into 2-3GB [3 and 4GB only achievable with some tricks...] memory space. So many developers jumped on the occasion to make their plugins 10x bigger with newer, resizable graphics and still using old DSP code. In other words to make some more money for doing... not much. I'm pointing at Arturia and IK Multimedia, for example. I'm still using older versions because I don't see the point in using newer ones as I don't have a 10000x5625pix screen and many other people don't yet use 4k screens, either.

Most of the 64bit plugins use more CPU and resources in general, so if your computer is low on RAM and CPU and you don't use huge sample libraries [I don't], then you're better off using 32-bit OS and DAW. In a 64-bit OS, why not? W7x64 works perfectly with 32-bit Reaper and 32-bit plugins.

Regarding VST3, you got it right ia, generally. I've been involved in a couple of discussions where developers discussed VST3 and said it's ridiculous and not needed. It really is mostly marketing talk behind it, nothing else. In my [hefty] experience, VST2 plugins are more stable and use less CPU, but when one is using Cubase 7/8/9... There really are advantages to using VST3 plugins with Cubase and it's recommended. For every other DAW, that's not really true. It gives us one more technical thing to have to think about before installing a plugin. Mainly depending on the DAW you use, because many of them still don't support VST3 properly. So generally you're better off just using VST2 plugins, if you're not a Cubase user.

 

Last edited: Dec 13, 2017

Ivory 2 (which contain ivory 1 library) and trilian (which contain trilogy library). Learn how to use google.

 

You can use a 3rd party bridge like jBridge. The thing is that they dropped their own bridge because they are incapable of making one properly and blamed it on "stability" which is pure nonsense. Stability because they are incapable of writing a proper bridge (not even concerning bitness btw), that's what it is.

As I said, bridges are not just for 32-bit <-> 64-bit communication, they are for stability because it isolates the plugin from the host. Bitwig even uses bridges by default (also called "firewalling") even if you only use one "bitness". You can make Reaper also do that natively with no 3rd party bridging. Such DAWs have the option to bridge just to increase stability and protect your host even if you aren't interested in different architecture plugins. So where's Steinberg's bridge? Shouldn't they have improved it and also make it work to protect Cubase instead of ditching it? Maybe removing things is easier if you're incapable of fixing the reason they crash, because if Steinberg's bridge crashed Cubase, it is fully the fault of Steinberg here, not the plugin. A bridge is supposed to isolate the host from the plugin, after all. If it doesn't, they failed at it, and they insist on pointing the fault at others because I'm sure that's how they're going to improve their code!

Yes you get a small overhead with bridging, which it can add up if you use tons of bridges though, so best to put up a group of plugins in one bridge instead of individually, or only the unstable plugins in bridge. But you get stability in return even if you use the same bitness/architecture.

So a properly designed bridge protects the host from a crashing plugin; i.e. it makes it more stable since the plugin will not be able to take down the host with it, which is totally the opposite of what the dummies at Steinberg claim.

Proper bridges don't make things unstable, they make it more stable at a small overhead (but it can add up, see above).

A proper bridge will never crash the host, no matter if the plugin it is hosting crashes or does anything (except if it removes your files, which is more like malware than just a bug, lol)

 

I prefer DDMF Metaplugin to JBridge. Because it can save whole chains of plugins. Really handy.

 

Thank you so much!!!

 

That's how Steinberg is doing advertising and all that marketing. 64 bit daw is a good point actually, cuz you can use 64 bit plugins in it. For example Kontakt sampler needs more than 4 GB RAM (if you're using modern huge libs, e.g. spitfire mural or something from orchestral tools) for smooth performance cuz if you have less than 4 GB RAM you will see how kontakt swapping samples from your slow HHD to fast RAM. That process takes time and slow up your system. And here comes 64 bits - it's just the way for 64 bit plugins to get access for more RAM than 4 GB for storing your samples. BUT if your daw doesn't allow you to use 32-bit plugins it's bad point, cuz there just no need for 64-bits in your average synth or dsp processor.

 

Last edited: Dec 15, 2017

but I want ivory 1! and trilogy! I want to use these old fashioned things sometimes (if I have certain mood for that), so learn how to read (try to read word by word slowly). and again - plzzz be more gentle - this is very important in social communications

 

Last edited: Dec 15, 2017

I'm having this problem now in Cubase 8.5 with the latest release of Windows 10 x64 Build 17107. .Net Framework 4.7 is built into windows and cannot be rolled back to an older version. Is anyone else getting this problem? Some help would be very much appreciated.

EDIT:

I was able to resolve the problem. It was not a driver, memory, or .Net issue, it was the Windows "Scale and Layout" settings for high DPI displays. Apparently it behaves differently in the latest version of Windows 10, because I had the same scaling settings before and did not have this GUI problem in Cubase. I have my scaling set to 150% on my 4K monitor so that everything does not look microscopic, which now apparently breaks Cubase's ability to display plugins correctly.

I solved the issue by right clicking on the Cubase icon and going into properties> compatibility> override high DPI scaling behavior> and selecting Scaling performed by: application. This solves the graphical glitches, but at the cost of everything in Cubase appearing extremely small.

 

Last edited: Feb 28, 2018