Hi.
I’m building a 32 bit host using the PluginListComponent.
My question is, When scanning a plug-in directory that contains also a 64 bit plug-in, it will just skip it, right?
And another thing ,how common are 64 bit plug-ins? should I consider moving to 64 now? or should I wait for Jules to build a 64->32 bridge like Steinberg did?
Lots of questions…
Thanks.
A plugin scan run in a 32 bit build does not see the 64 bit plugins and vice versa. For that reason I am using different filenames for the cached XML plugin list for 32 and 64 bit, so they do not clash.
Currently I am running two instances of the same host, one 32 bit and the other a 64 bit build. I’m planning on merging their audio output somehow, i.e. have the 64 bit host pull the output from the 32 bit host. One of the hosts has to be headless, i.e. without a GUI, of course. As it just spawns plugin windows anyway, that should not be a problem.
I would also be interested in learning how a bridge would be best implemented.
Thanks Ans
When you say “does not see” you mean that the LoadLibrary() just returns false after trying to load the plug-in’s DLL (Win), right?
I’m relying on Juce’s cross-platform KnownPluginsList, the directory scanner and associated classes, so I can’t say exactly at which point the plugin is “not seen”, but it definitely does not apper in the resulting list.
At least on the Mac. Things are a bit different here, as you can have Universal 32/64 bit binaries. Either scan that enumerates the available plugins “sees” one or the matching portion of that combined binary, depending on the build architecture of the scanning program.
IIRC, on Windows you have different DLLs per architecture, obviously also with different names. I don’t think a 64 bit Windows program can load 32 bit DLLs. Therefore I guess that an attempt at LoadLibary() returns an error that is handled by Juce.
I haven’t had the time to verify this, though.
Checked this now: It is impossible to load 32 bit code (DLL) into a 64 bit host program:
Hence any solution for supporting both 32 and 64 bit plugins in the same host involves spawning two separate OS processes and handle their communication via IPC. Don’t know if pipes work between these processes, though. IPC based on IP has some more overhead, but that’s nothing to really worry about on modern machines. The loopback interface (127.0.0.1) is very fast.
Such a “bridge” is relatively complex, the pure audio/MIDI streaming being the least challenging part. It’s the many commands you need to edit your AudioProcessorGraph, open/close plugin windows, load/unload plugins etc. All that needs to be done remotely via IPC on behalf of the master host process.
No wonder that even the market leaders are having a hard time to come up with a stable bridge.
Does anybody know a host that got it right with the bridge?
My current mindset is that we shouldn’t do it, let the user do the work of starting 64/32 bit application according to his desired plugins.
You better just put all this effort in making your host better.
Absolutely. I am not going to provide a bridge for my host.
