ProTools load problem....
-
@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.
-
@Dan-Korneff yeah - let me think about it for a bit....
-
my hacky solution is to tell customers to use a better daw
-
@iamlamprey I use a similar solution, I don't provide an AAX :)
-
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. -
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.
-
@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?
-
@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.
-
@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.
-
@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.
-
@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).
-
@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.
-
@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.
-
@Dan-Korneff oh well yes if that works in ProFools then great!
-
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 but didn't this change the default values of the parameters?
-
@Dan-Korneff said in ProTools load problem....:
@gorangrooves but didn't this change the default values of the parameters?
yeah - this == bad.
-
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.
-
@Christoph-Hart I guess, this will only work for those who utilize presets in their plugins.
@Dan-Korneff Yes, it sets the "default values" of parameters to that what you set on your GUI as the default state of your plugin. Isn't that the objective?
If I set a slider to a value of 0.5 on the GUI to be loaded when a user opens up the plugin, why would I want the default value of that slider to be anything different from that?
Basically, you make your adjustments for the controls on the GUI to be what you want them to be in every DAW, and the little script sets the default values for those controls to the same values.The secondary script on the page I pointed to, gets the Pro Tools to recall those values if one slider moves to a value we know it should not be on load.
@Lindon What's bad?
All I can tell you is that I have implemented this, and it works perfectly.