PluginDescription 32/64 bit


#1

Possibly I miss something, but wouldn’t it be useful to add an “architecture” field to the PluginDescription?

My host would need to distinguish between 32/64 bit plugins, because it has to lookup the appropriate version (actually: its saved preset state) depending on itself being a 32 or 64 bit build. That is, the saved projects are supposed to be portable across 32/64 bit incarnations of the host.

It would be great if the architecture field could be added.


#2

No… doesn’t seem appropriate to me. If you have two versions of a plugin that are incompatible for whatever reason, why not just give them different versions numbers or names?


#3

Supposed you have two “Kontakt 3 8out” plugins for both 32 and 64 bit. The host re-opens a document that identifies a needed plugin as “Kontakt 3 8out” plus “VST”. Now when the 32 bit version of the host is run, it should pick the 32 bit Kontakt, and if a 64 bit build is run, else the 64 bit Kontakt respectively.

I know they probably have different filenames, versions, descriptive names, or something (and on OSX they are likely a universal binary), but that’s not the point. I need the host to run a query of the sort “find the most similar compatible plugin on this architecture that can load this saved preset state”.

That is, I want to have one host document that opens on both 32 and 64 bit OS.


#4

Oh, I see what you mean. Well, the incompatible ones won’t be found in the plugin scan anyway, so surely it’s just a case of looking for something with a similar name…?


#5

Ah, I forgot that. Well, then I should use different filenames for the cached plugin lists. I know of users who switch between 32/64 bit mode every other day. The cached lists should survive that.

In theory, yes. However, a similar name does not imply compatibility concerning the saved states. I’m pretty sure all incarnations of Kontakt 3 can load their respective states, but their manufacturer field sometimes is “Native Instruments”, sometimes “NativeInstrumentsGmbH”, etc. There is no reliable way to match these for arbitrary manufacturers.

My hope is that an identical plugin which only differs in CPU architecture uses identical fields. If that’s the case, it would at least work for AudioUnits (universal binary, same file). Not sure whether it would also work for VST (separate filenames?).