As the title says - the first thing I have to go and do every time I make a new Projucer project (or open a default one like the plugin host example) is change the build from 32-bit to 64-bit. JUCE defaults to 64-bit for Linux and macOS, why not Windows? It’s 2016, and I know exactly zero people with a 32-bit processor in their PC.
Additionally, for plugins a lot of DAWs won’t even load 32-bit plugins anymore, which could very well put off new folks compiling the example plugins who might not be able to get them to load.
(Almost as annoying as the way that if you aren’t on the very latest OSX, then when you launch the default project without changing the settings, it won’t run because of the OS version compatibility settings defaults!!)
I’d say the majority of juce developers are on 64-bit machines, and likewise they foremost develop 64-bit stuff. That said, of course some will eventually make 32-bit versions of some of their stuff, but the deafult settings for all samples and demos should pref be 64 bit.
Yes, I’m aware of this and know there’s a decent population of musicians who use ancient PCs because that’s what they’re comfortable with. If there’s some customer who demands running Cubase 4 in Windows XP for whatever reason and a JUCE developer chooses to support them, that’s their choice and that’s fine - I’m not suggesting JUCE drop 32-bit Windows support and I don’t think it should by any means. That’s not really what I’m talking about in this post. I’m saying that the default architecture for VS2010+ projects should be 64-bit.
While this is the true for standalone apps, it gets more complex for audio plugins. The architecture of the DAW needs to be the same as the architecture of the plugin in almost all cases. In fact I’m not aware of an exception where a DAW has a jbridge-like 32-64 bridge built in.
Like I said, my main concerns are that this can cause issues for people who might be trying out JUCE for the first time and can’t figure out why their 32-bit default compiled plugin won’t load in their 64-bit DAW. Also, it’s annoying for us developers who are likely overwhelmingly on 64-bit PCs.
Another interesting idea would be to choose based on the user’s current architecture at target creation time in the Projucer. I.e. if the user is running 64-bit Windows, when creating a new VS target choose 64-bit or vice versa. But that’s definitely a really elaborate feature for something most people won’t even notice vs. just making the modern 64-bit architecture the default.
Hmmm tough one. I agree that standalone apps should be 32-bit as they will run on all systems. Plug-Ins: I feel that it’s probably the time to move to 64-bit as most developers will be testing in 64-bit hosts and using a bridge makes debugging pretty difficult.
The one exception is the standalone host app. If we are moving to 64-bit plug-ins then the host app also needs to be 64-bit.
And it would be super-helpful actually if the Host App built two binaries, with different names PluginHost32bit and PluginHost64bit. It would have saved me going round in circles a lot early on, and probably would still late at night when I can’t work out why the debugger won’t work or a plugin won’t scan