UAD is going native but according to UAD support the native counterparts of their plugs will have different IDs than their DSP counterparts so opening an old project that used UAD DSP plugins versions will not work when opening this project with only UAD native counterpart plugins versions installed. this would only be possible if one can either manually edit a plugin ID in cubase (so i could change the native plugins IDs to their DSP plugins counterparts) or kinda link 2 different plugins IDs so cubase will know that it has to open the UAD DSP plugins with their UAD native plugins counterparts.

 

The use of the term "counterpart" is probably not what they have in mind. Your "migration" probably wasn't either.

 

i got no clue and dont care what they had in mind with this. i just care about how this can benefit me.

i did some research by now and it seems it can be done. i ll just need to manually edit the native plugin's ID (setting it to its DSP counterpart's ID) using a hex editor. but i therefor will need to find out the plugin IDs of the native plugins (to overwrite) as well as the the DSP plugins (to copy from). anyone knows how to do that? i know they can be found when viewing the .dll (DSP plugins)/.vst3 (native plugins) files with a hex editor but how do i find/identify the plugin ID in these files/code gibberish?

 

Might be easier to save presets in the hardware ones or make print screens of the settings. Remember each time UAD updates their native plugins you need to change the ID again. Also it is very close to April first. But it is on their own website, so I guess not.

 

I'm quite interested in the native UAD plugins CPU consumption.

Changing the ID is possible the way you described it, but indeed how to find it? I'm sure [I saw IDs in one f the VST bridging programs] there are some programs that can reveal the plugin ID. Maybe JBridge? At some point I used some FXpansion VST bridge that was pretty neat, but it's really hard to find as it's been discontinued very soon after it'd been released.

 

The problem with changing the ID is that it will only work properly if the internal structure of patch serialisation remains the same, and that's unlikely. You're likely going to be better off with keeping the IDs separate so that you can make a preset of the settings, then load the new plugin in it's place and load the preset you just made.

The plugin ID itself is the very smallest part of compatibility.

 

in general yes, but not in my case since UAD support confirmed that the native and DSP versions are coded exactly the same, hence all the plugins' parameters are the same and therefor total recall will work.

 

thx. any chance finding out which app/plugin it was exactly that you used to show plugin IDs?