Modify the AAX SDK to help users with plugins that have numbered versions - Kontakt,

[massivekerry]

I already posted this on the Avid Link lounge for PT Feature Requests. But I figure, what the heck... if you agree, do there and upvote it.

This request is to modify the SDK for AAX developers in a way that that will allow automatic migration between different versions of a plugin that have different plugin IDs. Yeah, big balls on me for asking that right? Hear me out.

The only devs that I run up against this problem with are Native Instruments and iZotope (same parent company now). The real issue is with NI’s Kontakt.

I (and many colleagues and peers) run large orchestral templates with hundreds of Kontakt instruments loaded, and live in fear of having to migrate to a new version… because even though we thought that NI had seen the light when they named “Kontakt v6” to be just “Kontakt”, in 2022, the new version is now “Kontakt 7” in the plugin list. Unfortunately, this new version is the one that they are updating and optimizing for Apple Silicon, and Pro Tools is only just getting its Silicon Native version going.

So, if in the near-future I want to use PT in Native mode and not Rosetta, I will have to update to Kontakt 7. I don’t mind paying for the upgrade. But I do very much mind the hours (and likely days) that it will take to re-configure my Pro Tools template so that the Instruments load in “Kontakt 7” (this will require removing the Kontakt [6] instances, and loading Kontakt 7 instruments in their place, and then loading the actual sample instruments (and any settings that might be important - or saving each NKI Instrument to open in K7). If NI was able to put some kind of pointer saying "please migrate these instruments to the new version without changing anything", that would be a great help. We could install Kontakt 7, place the Kontakt [6].aaxplugin in the "Plug-Ins (Unused)" folder, open our template, wait for everything to load properly, and... happy composers.

I was sticking my head in the sand about this. And I’m sure that now there will be some dodgeball between Avid and NI reps over responsibility ("NI doesn't HAVE to re-name their plugins..."), with the users still ultimately taking ball in the face.

But… NI recently had an “Ask Me Anything” on their “Community” site, and NI implied that the plugin frameworks (AAX, AU) could be modified to allow “migration between different versions of a plugin that have different plugin IDs.” In fact the VST3 SDK recently added this ability.

So, I don’t know the how’s, if’s, possible’s of the matter, but I would be extremely happy if Avid might PLEASE reach out to NI/iZotope/Soundwide (hey, our AAX DSP pal Dirk is on the Board now, right?) and quickly find some way to work together to at least allow us Kontakt-reliant composers to upgrade our systems over the years (and especially now with this Apple Silicon migration) with a minimum of the pain that is currently required to do so?

Thank you.



The pertinent comments from Aaron, the QA for the Kontakt team are below:

This is indeed a valid topic. Up until recently it was not easily possible, but recent additions by Steinberg to the VST3 SDK allow doing this as you describe - automatic migration between different versions of a plugin that have different plugin IDs.

On the Kontakt side, we are working on implementing this mechanism, but it also goes hand in hand with DAWs implementing this. Cubase, Reaper, Maschine and Komplete Kontrol already have this in place, I fully expect other DAWs will follow.

This is for the VST3 case. Regarding AU and AAX, this is not in place yet within those plugin frameworks (it did work for AU in Logic for a time, but is currently broken due to a bug). My assumption is that once it is common-place with VST3, the other targets will also implement this, but of course over this we don't have control.

https://community.native-instruments...e-kontakt-team

[bradch00]

I haven’t gone through the vst3 spec, but is this like configuring an alias? I have thought about this for a long time. You configure an instrument called “KontaktVI” or whatever with your DAW, which points to the actual version/plug-in that you are using.
Not sure how far fetched of an idea it is.

[smurfyou]

How would this work though with versions that are incompatible and with different feature sets? Izotope RX has been really annoying about this but the plugins are not compatible between versions. So even if it would "migrate" the settings wouldn't be the same or it would change the mix. Not to mention the parameter naming and ranges.

K7 can import K6 but the plugin container itself has changed. I'd love to know how NI tackles this.

Great idea but I can't wrap my head around how it would realistically work. I guess for a template like you have it would be easier than an existing dynamic composition and mix? Since it would just be static settings to be imported and migrated.

[originalscottyg]

Originally Posted by smurfyou

How would this work though with versions that are incompatible and with different feature sets? Izotope RX has been really annoying about this but the plugins are not compatible between versions. So even if it would "migrate" the settings wouldn't be the same or it would change the mix. Not to mention the parameter naming and ranges.

K7 can import K6 but the plugin container itself has changed. I'd love to know how NI tackles this.

Great idea but I can't wrap my head around how it would realistically work. I guess for a template like you have it would be easier than an existing dynamic composition and mix? Since it would just be static settings to be imported and migrated.

I agree that Izotope make this implementation difficult. I have always thought that they should include the legacy algorithms in the updated versions and include a legacy algorithm option; one that would automatically activate when opening a session with legacy versions. For example, there is a track with RX Voice-Denoise version 7 on it, but the session is opened on a system with only RX v9 (not that I really use any RX plugins real-time in 99.999% of cases). The track would open with the Voice-Denoise v9 plugin taking the place of the v7 plugin on the track, but with the Legacy v7 algorithm activated so all the settings and sonics match. Extra work and coding on their part, but it just might make paying for upgrades a lot more appealing for many people. Just my 2¢.

[massivekerry]

I agree with you guys. Every once in awhile I open an old session that had Ozone 5 on it, and used the O5 reverb (it had a sound that was occasionally useful). There are larger issues present in the overall idea than the one I highlighted, but that's why I think this is an important issue to get in front of the industry and apply some gentle but reasonable pressure to the devs/companies to do what they can to streamline this process. At least NI and iZotope are both part of Soundwide now and maybe can be approached together. Arturia is one of the other offenders for me, but that seems easier to get around, perhaps because I don't pre-load patches on their synths.

We're a whole industry of users that solve problems and engineer solutions to things regularly. Maybe together we can incentivize the devs to provide better, more flexible migration and use pathways when they update their products.

[massivekerry]

Originally Posted by bradch00

I haven’t gone through the vst3 spec, but is this like configuring an alias? I have thought about this for a long time. You configure an instrument called “KontaktVI” or whatever with your DAW, which points to the actual version/plug-in that you are using.
Not sure how far fetched of an idea it is.

Yeah, I'll fully admit that I have no idea what the math or coding process involved in this would be. I just hope to stir enough publicly-voiced interest that the devs are willing to tackle whatever is required to accomplish it.

I do think there'd need to be some user-involved process or option. It might be physical, like having to remove the old plugin from the plugins folder to get the data to migrate to the new one automatically, or some kind of preference (which sounds complicated) or side-by-side version installations (like it is now). The comments about RX features changing with time is a valid one, and if you own the license to an older version that has a unique feature (and it remains compatible with the system and OS) you should be able to use that version as well.

[gives]

Originally Posted by massivekerry

I already posted this on the Avid Link lounge for PT Feature Requests. But I figure, what the heck... if you agree, do there and upvote it.

This request is to modify the SDK for AAX developers in a way that that will allow automatic migration between different versions of a plugin that have different plugin IDs. Yeah, big balls on me for asking that right? Hear me out.

The only devs that I run up against this problem with are Native Instruments and iZotope (same parent company now). The real issue is with NI’s Kontakt.

I (and many colleagues and peers) run large orchestral templates with hundreds of Kontakt instruments loaded, and live in fear of having to migrate to a new version… because even though we thought that NI had seen the light when they named “Kontakt v6” to be just “Kontakt”, in 2022, the new version is now “Kontakt 7” in the plugin list. Unfortunately, this new version is the one that they are updating and optimizing for Apple Silicon, and Pro Tools is only just getting its Silicon Native version going.

So, if in the near-future I want to use PT in Native mode and not Rosetta, I will have to update to Kontakt 7. I don’t mind paying for the upgrade. But I do very much mind the hours (and likely days) that it will take to re-configure my Pro Tools template so that the Instruments load in “Kontakt 7” (this will require removing the Kontakt [6] instances, and loading Kontakt 7 instruments in their place, and then loading the actual sample instruments (and any settings that might be important - or saving each NKI Instrument to open in K7). If NI was able to put some kind of pointer saying "please migrate these instruments to the new version without changing anything", that would be a great help. We could install Kontakt 7, place the Kontakt [6].aaxplugin in the "Plug-Ins (Unused)" folder, open our template, wait for everything to load properly, and... happy composers.

I was sticking my head in the sand about this. And I’m sure that now there will be some dodgeball between Avid and NI reps over responsibility ("NI doesn't HAVE to re-name their plugins..."), with the users still ultimately taking ball in the face.

But… NI recently had an “Ask Me Anything” on their “Community” site, and NI implied that the plugin frameworks (AAX, AU) could be modified to allow “migration between different versions of a plugin that have different plugin IDs.” In fact the VST3 SDK recently added this ability.

So, I don’t know the how’s, if’s, possible’s of the matter, but I would be extremely happy if Avid might PLEASE reach out to NI/iZotope/Soundwide (hey, our AAX DSP pal Dirk is on the Board now, right?) and quickly find some way to work together to at least allow us Kontakt-reliant composers to upgrade our systems over the years (and especially now with this Apple Silicon migration) with a minimum of the pain that is currently required to do so?

Thank you.



The pertinent comments from Aaron, the QA for the Kontakt team are below:


https://community.native-instruments...e-kontakt-team

This jsut popped up for me J
Just saw this in my Native Access and not sure if it's been posted about. Kontakt 7.1.8 update, but could not see what has been changed in info in my Native Access portal.

G

[massivekerry]

Originally Posted by gives

This jsut popped up for me J
Just saw this in my Native Access and not sure if it's been posted about. Kontakt 7.1.8 update, but could not see what has been changed in info in my Native Access portal.

G

I don't think it deals with that issue yet. A bunch of us started getting into it on VI-Control last month, starting at about reply #1082 (page 55).

VI Control - Kontakt updates

[Piotr Kubiak]

I using Pro Tools for post and cubase for music. I know that axx is different than vst, but I migrate my cubase project with kontakt 5 to kontakt 6 using hex editor and changing all vst id code in project. All instruments and automation migrate without a problem. Now kontakt 6 is just kontakt and propably it will not need to make that hex editing when I will upgare to kontakt 7.

I didn’t try it with izotope but i’m sure that will not work. All izotope new version are completely new product. That is discounting :) I thinking of stop using they product becouse of that exept rx with I using only offline.

With waves, audioease and other manufactures I can load my very old session without no problem, izotope releasing more and more. Plugins are not compatible and looks different and have new bugs!

I really like neutron eq how it sound, also it was so many surround tools in netron that I started to use that in almost every postproduction project. I missed version 2 and upgraded to version 3. New gui! More like fab filter, I lost so many time to used to! And some of features stop working! This is terrible :/

[Eric Lambert]

Kontakt has bit us in the ***** more times than I can remember for the reasons you've pointed out. And it's why they've stopped numbering Kontakt and simply call it "Kontakt."

We had to keep multiple versions of Kontakt around just for those instances where a session used "Kontakt 3" but our current version was called "Kontakt 4" and the session wouldn't load properly.

It's going to be an issue when we go Native and older versions don't get the update. At this stage I'm not even sure that 6 will be usable in PT Native.

To address your concern, YES, it's an annoying and silly issue which not every developer forces us to deal with.

sidenote: Massey allows you to drag-n-drop between older and newer versions of its CT compressor. I think that's brilliant and I don't know why more devs haven't done this.

Coincidentally, I was just suggesting Massey's method to a large company who's come against this hurdle. I think they had trouble figuring out how he did it.