ProTools load problem....

[Lindon]

@Dan-Korneff Thanks Dan thats the implementation I was thinking of using - ugly as it is...

[Dan Korneff]

@Lindon I came up with this one quickly cause I was in a hurry, and it worked, but I'm sure there's much room for improvement.

[Lindon]

@Dan-Korneff yeah - let me think about it for a bit....

[A Former User]

my hacky solution is to tell customers to use a better daw

[d.healey]

@iamlamprey I use a similar solution, I don't provide an AAX :)

[Christoph Hart]

Is there any valid use case for why the default state of a plugin should be different from the defaultValue property of each UI element? This is nagging me for years because you have to drag around an "init user preset" and restore it everytime you save the project to not mess up the git history.

I'm thinking about adding an Enforce Default State mode that will restore the values of each UI element to the default state defined by the defaultValue property whenever you save or export the project and this would drive-by-fix this annoying Protools problem too.

[d.healey]

I can imagine it's not uncommon to have "safe" default values for the user's benefit when they are tweaking the controls but for your default preset you want different settings.

[Christoph Hart]

@d-healey yeah I think I‘m going through the projects and compare the init state vs the default value, but what if we just add a initValue property that will take precedence over the defaultValue at initialisation so you can customize those controls individually?

[d.healey]

@Christoph-Hart That's good. I think even better would be if we could assign a "default preset" that would also be selected in the preset browser.

[Dan Korneff]

@Christoph-Hart said in ProTools load problem....:

Is there any valid use case for why the default state of a plugin should be different from the defaultValue property of each UI element?

For something like a mixing console, the default value for a fader would be set to 0dB, but that could be way different than the balance you may have dialed in for your default state.

[Dan Korneff]

@Christoph-Hart said in ProTools load problem....:

what if we just add a initValue property that will take precedence over the defaultValue at initialisation so you can customize those controls individually?

Could this be generated automatically from the export state? If you have 100 controls, you'd have to manually verify that the initValue matches the value of your export state. I can't think of a reason why these would ever be different.

[Christoph Hart]

@Dan-Korneff yeah the suggestion of David makes more sense, so I‘d go that route - you will just have to specify a default preset in the settings and it will use this as init state and plugin parameter default state (which solves the Protools issue).

[Lindon]

@Christoph-Hart said in ProTools load problem....:

Is there any valid use case for why the default state of a plugin should be different from the defaultValue property of each UI element? This is nagging me for years because you have to drag around an "init user preset" and restore it everytime you save the project to not mess up the git history.

I'm thinking about adding an Enforce Default State mode that will restore the values of each UI element to the default state defined by the defaultValue property whenever you save or export the project and this would drive-by-fix this annoying Protools problem too.

Actually-if understand this correctly- this would be the exact opposite of fixing the problem. Every control needs a default state - but the plugins init state may well need to be a specific preset (so the user gets a "good" experience straight away).

So if I set the plugin to this init-preset on compile, then every other DAW loads the plugin AND its init-preset state. ProTools loads the plugin and ignores this init-preset state and just sets every control to its default...=== bad,bad,bad PT.

So what we need here is a mechanism to force the load of this init-preset in ProTools.

[Dan Korneff]

@Lindon I think @Christoph-Hart is suggesting that he adds a feature to load a specific preset when you launch your plugin. Like an automatic version of my hack.

[Lindon]

@Dan-Korneff oh well yes if that works in ProFools then great!

[gorangrooves]

Hey guys,
I dealt with this issue before releasing my Handy Drums update v1.4. Here is a solution.

The default values of my controls were different from that of what the actual sliders and knobs were set to. I made a simple script to get the current values of all controls and set the default state of all controls to those values. I run the script once before compiling the plugin, then comment it out.

The result is that both the default values and current values match. So, PT opens up the plugin exactly as any other DAW. Tested and working.

@Lindon Try it out.

[gorangrooves]

Here:
https://forum.hise.audio/post/57305

[Dan Korneff]

@gorangrooves but didn't this change the default values of the parameters?

[Lindon]

@Dan-Korneff said in ProTools load problem....:

@gorangrooves but didn't this change the default values of the parameters?

yeah - this == bad.

[Christoph Hart]

Alright, I've pushed something that should take care of this problem. You can now define a relative path in the Project settings to a user preset file (from the user preset directory) (DefaultUserPreset) that will be embedded into the binary and loaded as default state. Once you've done this, this preset is being loaded everytime you save or export the project. It will also return the value stored in the preset as default value for the plugin parameter which should hopefully fix this Protools issue once and for all.

What I haven't done yet is to make this the selected preset on init, but that's something for another day :)

Let me know if that helped.