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.