Thinking of going 64 bit only...

[mystran]

because technically it no hassle as you can build universal executables in a single run.

Until you have a dependency library that provides a "helpful" build process that hasn't ever heard about universal binaries and uses command-line defines (or something similar) to pick the architecture just to make sure you have to compile twice (eg. I have yet to figure out how to avoid doing this with Freetype).

[quikquak]

I presume you’ve told Freetype? They seem to like supporting different OSs.

[mystran]

- int64_t is handy for some stuff
- large allocs and/or memory maps are hardly a problem on 64-bit,

I'm nowhere near doing anything of that scale yet. If I ever have to load in huge swaths of samples, then I can start worrying. However, I started programming with 4k of RAM, so minimizing the use of resources is extremely ingrained in my programming style. I laugh at myself when I throw more memory at a speed problem and I end up using only 64k more in the end. Old programming habits die hard as I drag myself out of the 70s and into the world of "limitless" resources.

With large allocs in particular, hitting the "maximum continuous block" limit is actually a lot easier than hitting the "maximum memory per process" limit. The reason is that while you might be able to get 3GB (or whatever) of memory into the process, the actual address space can get pretty fragmented especially after the process has been running for a while.

So you might end up in a situation where you have 1GB of free heap space, but malloc()/new might still fail for a continuous block of 200MB, which is only about 10 minutes of audio for 32-bit floats 44.1kHz stereo.

[mystran]

I presume you’ve told Freetype? They seem to like supporting different OSs.

I haven't bothered really. It compiles just fine using the generic "unix" target, you'll just have to merge two builds for universal binaries manually. I have a few other issues with Freetype's design decisions anyway, so I'm not sure if I'm going to use it in the future.

As far as I'm concerned the auto-hinter is really the only advantage over something like stb_truetype and with high-DPI displays getting more common I'm not quite sure if I should even bother anymore.

[lorcan]

I haven't bothered really. It compiles just fine using the generic "unix" target, you'll just have to merge two builds for universal binaries manually.

I just put the all the .c files in a master .c 'unity build' file and include that in the XCode project.
Works fine to build a universal binary + no linking required.

[Timfonie]

I didn't switch completely yet are doing it gradually.

In the past I used jBridge to run quite a few 32bit plugins in a 64bit environment (Windows 7 and Cubase).
My current setup, based on Cubase 9.5 also runs some 32bit plugins but only a handful of them. I still can't part with synths like SQ8L.

So there's no need to abandon any and every 32bit plugin. You can do it stepwise as long as your DAW runs @ 64bit.

[mystran]

I haven't bothered really. It compiles just fine using the generic "unix" target, you'll just have to merge two builds for universal binaries manually.

I just put the all the .c files in a master .c 'unity build' file and include that in the XCode project.
Works fine to build a universal binary + no linking required.

Oh I see, good to know... although I have no idea how to use Xcode and since I used Linux as my primary desktop for over 10 years (back before I started messing with audio code), I've pretty much internalised GNU make to the point where it's faster for me to put together a few Makefiles than to figure out how Apple would like me to do things

But yeah, I suppose I could just throw away Freetype's build system and replace it with a generic Makefile. I'll probably try that next time I need to compile a new version.

[syntonica]

... although I have no idea how to use Xcode

Xcode is great if you are programming in their new baby, Swift, and formatting your code in their proscribed (demanded, even) style. Everything else these days is a second- (or third-) class citizen, including even Objective-C. When Apple cuts of support for something, even the good PDFs that describe in detail disappear from the web. That is the power of Apple.

[Aloysius]

Keep 32-bit alive on Windows.

Rob Papen is supporting the following with his new synth, so I will support him:

PC: 32 & 64 bits VST and AAX for Windows Vista / Windows 7/ Windows 8/ Windows 10
(Note: PC AAX for PT 12 or higher)
Mac: 32 & 64 bits AU, VST and AAX, for OSX 10.6 or higher.

[luzifer]

we still see a relatively high download rate for 32 bit binaries for windows. we develop and profile/optimize for 64 bit obviously and just do QA for windows 32. i don't have the impression that keeping the door open to both is a major obstacle during development. just packaging is a bit of a pain.

that said: what is your preferred way of releasing windows 64 installers? we currently package a 64 bit standalone and a 32 and 64 bit vst into the win 64 installer. which obviously also means that we have to distribute runtimes for both platforms.

[quikquak]

Keep 32-bit alive on Windows.

Rob Papen is supporting the following with his new synth, so I will support him:

PC: 32 & 64 bits VST and AAX for Windows Vista / Windows 7/ Windows 8/ Windows 10
(Note: PC AAX for PT 12 or higher)
Mac: 32 & 64 bits AU, VST and AAX, for OSX 10.6 or higher.

I thought AAX didn't work in Pro tools as 32 bit?

[Aloysius]

I don't use amateur tools (aka pro tools).

[quikquak]

I don't use amateur tools (aka pro tools).

Plenty of people do, but my question was, does anybody even run 32 bit AAX? I thought AAX was introduced when they phased 32 out? I’m probably wrong...

[lorcan]

Plenty of people do, but my question was, does anybody even run 32 bit AAX? I thought AAX was introduced when they phased 32 out? I’m probably wrong...

ProTools 10 supports 32bit only, 11+ 64bit.