|
08-20-2019, 09:48 AM
|
#1
|
Human being with feelings
Join Date: Apr 2018
Posts: 396
|
"Bool" parameter problem in AAX builds
Have a strange one here - not sure if it's a bug in iPlug or in Pro Tools.
Every "bool" parameter in my plugin responds to automation values when jumping around the timeline with transport stopped but does not respond when transport is running. On playback the variable will properly switch from OFF to ON but then never turns off thereafter (it's latching at "1/True").
Happens in Pro Tools on both Mac and PC.
These same controls work perfectly in VST/VST3 and AU apps.
Anyone else come across this?
BTW - I'm trying to run this in MSVS Debugger but I get a continuous stream of: "Exception thrown at 0x000000000F74FBE2 (ProTools.dll) in ProTools.exe: 0x80000004: Single step" and can't debug. Not sure what's wrong there.
|
|
|
08-20-2019, 10:05 AM
|
#2
|
Human being with feelings
Join Date: Sep 2009
Posts: 623
|
Yep. It's a pain. The only solution I've found that works is to make bool, int or enum parameters doubles with a resolution of 1.0 for AAX plugins.
|
|
|
08-20-2019, 10:24 AM
|
#3
|
Human being with feelings
Join Date: Apr 2018
Posts: 396
|
Quote:
Originally Posted by bozmillar
Yep. It's a pain. The only solution I've found that works is to make bool, int or enum parameters doubles with a resolution of 1.0 for AAX plugins.
|
Hmmm - that's strange because InitBool, InitInt and InitEnum functions all ripple through, and convert to, InitDouble in IParam.cpp anyway albeit with different "mTypes". So that must mean the problem is in "mType = kTypeBool"?
What I don't understand is why it works when the transport is stopped. If I click around on the timeline the plugin bool parameters react as they should. Press play and they do not. So transport running has something to do with this - but why/how?
When I check automation points written in PT every point in Bool automation lanes show "Off" even though, clearly, some should say "On" (see attached screenshot). I have checked other plugins and PT does not do this with them - so apparently it is a bug in iPlug AAX implementation somewhere.
Last edited by Nonlinear; 08-20-2019 at 06:22 PM.
|
|
|
08-21-2019, 10:24 AM
|
#4
|
Human being with feelings
Join Date: Apr 2018
Posts: 396
|
I found another post about this years ago (2016) but there was no conclusion to the thread. https://forum.cockos.com/showthread....highlight=bool
Was this ever resolved/fixed in iPlug or iPlug2?
|
|
|
08-21-2019, 10:43 AM
|
#5
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
The basic problem was that IPlug use AAX_CLinearTaperDelegate for enums/bools, I changed it to AAX_CStateTaperDelegate.
But there are other issues (rounding, for instance) with the AAX implementation that affect automation. See https://github.com/earlevel/wdl-ol/tree/earlevel.
|
|
|
08-21-2019, 11:41 AM
|
#6
|
Human being with feelings
Join Date: Apr 2018
Posts: 396
|
Quote:
Originally Posted by earlevel
The basic problem was that IPlug use AAX_CLinearTaperDelegate for enums/bools, I changed it to AAX_CStateTaperDelegate.
But there are other issues (rounding, for instance) with the AAX implementation that affect automation. See https://github.com/earlevel/wdl-ol/tree/earlevel.
|
Just before you posted this I tried changing IPlugAAX "case kTypeBool" to use the BinaryTaperDelegate instead of LinerTaperDelegate and now it works. "On" and "OFF" show properly in the automation lane as well.
In IPlugAAX.cpp under case IParam::kTypeBool:
Replace -> AAX_CLinearTaperDelegate<int>((int)p->GetMin(), (int)p->GetMax()),
With -> AAX_CBinaryTaperDelegate<int>(),
|
|
|
08-21-2019, 12:35 PM
|
#7
|
Human being with feelings
Join Date: Sep 2009
Posts: 623
|
I remember last time this came up that I tried that fix. I don't remember exactly what the deal was, but some other issues cropped up that made me revert back to the way I was doing it before. Maybe it was just the rounding errors, where the knob and the values didn't match up. If it was that, it seems like it should be a trivial fix, but I just remember every time I'd fix one thing, it would break something somewhere else.
I think in the end, I just came to peace with the idea that I won't use knobs with ints or enums.
|
|
|
08-21-2019, 04:38 PM
|
#8
|
Human being with feelings
Join Date: Apr 2018
Posts: 396
|
Quote:
Originally Posted by bozmillar
I think in the end, I just came to peace with the idea that I won't use knobs with ints or enums.
|
This fix is for "bool" parameters - buttons and switches.
|
|
|
08-21-2019, 06:50 PM
|
#9
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
So, the fix that works for enums and bools is to change AAX_CLinearTaperDelegate to AAX_CStateTaperDelegate. But there are rounding errors in the code too, so if you don't fix them, you'll think everything is working fine, given some controls, but later you'll realize that Pro Tools automation is showing different selections that your GUI is.
There are a few other annoying things, like integer controls displaying as "1.00" etc. All fixes in my branch here:
https://github.com/earlevel/wdl-ol/tree/earlevel
|
|
|
08-21-2019, 07:26 PM
|
#10
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
Quote:
Originally Posted by bozmillar
I remember last time this came up that I tried that fix. I don't remember exactly what the deal was, but some other issues cropped up that made me revert back to the way I was doing it before. Maybe it was just the rounding errors, where the knob and the values didn't match up. If it was that, it seems like it should be a trivial fix, but I just remember every time I'd fix one thing, it would break something somewhere else.
I think in the end, I just came to peace with the idea that I won't use knobs with ints or enums.
|
Yes, it sounds like you hit the rounding bugs, they were somewhat maddening. They required fixes in multiple places.
Echo Farm 3 AAX Mac/Win shipped in early 2017. AU/VST/VST3 support was added later, but otherwise there have been no revisions or bug reports, it's pretty solid. It uses double/int/bool/enum parameters.
|
|
|
08-21-2019, 08:30 PM
|
#11
|
Human being with feelings
Join Date: Apr 2018
Posts: 396
|
Quote:
Originally Posted by earlevel
Yes, it sounds like you hit the rounding bugs, they were somewhat maddening. They required fixes in multiple places.
Echo Farm 3 AAX Mac/Win shipped in early 2017. AU/VST/VST3 support was added later, but otherwise there have been no revisions or bug reports, it's pretty solid. It uses double/int/bool/enum parameters.
|
I see that you also fixed a Reaper presets bug in VST3. I haven't noticed any VST3 issues in Reaper - what was that about?
|
|
|
08-22-2019, 12:45 PM
|
#12
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
Quote:
Originally Posted by Nonlinear
I see that you also fixed a Reaper presets bug in VST3. I haven't noticed any VST3 issues in Reaper - what was that about?
|
The original IPlug implementation of VST3 host communication that includes handling presets is a bit rough.
Basically...Reaper has the wrong idea of how many step the menu has, by the VST definition, probably because IPlug told it wrong in the initialization (a two-value parameter has one step in VST terms, not two—the base and one step). In most cases this wouldn't matter—the host tells the plugin that the fourth item in the preset list is selected, the plugin brings up the fourth preset. But Reaper does an unusual step, to support preset renumbering by the plugin, it essentially tells the plugin which preset to select, then it asks which preset is now set. The catch is that it's a normalized parameter value, 0-1, This would still be OK if IPlug implemented both ways of the conversion functions, but it misses one side (normalizedParamToPlain was missing...but it didn't implement PlainParamToNormalized right either)—Reaper does it's own calculation. So, for a menu of 32 items, your plugin would think that's 32/32 = 1.0. Reaper would say 32/33. There's no harm if IPlug is equipped to do both sides of the calculation, or if Reaper didn't support renumbering with these calls—that's why other hosts didn't have that issue.
It's a little worse than that, because you fix some of this, then realize there are IPlug rounding mistakes and partial implementation, but if you get it all fixed it all works right on any host...in which VST presets are implemented, which is another fun inconsistency.
|
|
|
08-22-2019, 02:53 PM
|
#13
|
Human being with feelings
Join Date: Apr 2018
Posts: 396
|
Quote:
Originally Posted by earlevel
The original IPlug implementation of VST3 host communication that includes handling presets is a bit rough.
Basically...Reaper has the wrong idea of how many step the menu has, by the VST definition, probably because IPlug told it wrong in the initialization (a two-value parameter has one step in VST terms, not two—the base and one step). In most cases this wouldn't matter—the host tells the plugin that the fourth item in the preset list is selected, the plugin brings up the fourth preset. But Reaper does an unusual step, to support preset renumbering by the plugin, it essentially tells the plugin which preset to select, then it asks which preset is now set. The catch is that it's a normalized parameter value, 0-1, This would still be OK if IPlug implemented both ways of the conversion functions, but it misses one side (normalizedParamToPlain was missing...but it didn't implement PlainParamToNormalized right either)—Reaper does it's own calculation. So, for a menu of 32 items, your plugin would think that's 32/32 = 1.0. Reaper would say 32/33. There's no harm if IPlug is equipped to do both sides of the calculation, or if Reaper didn't support renumbering with these calls—that's why other hosts didn't have that issue.
It's a little worse than that, because you fix some of this, then realize there are IPlug rounding mistakes and partial implementation, but if you get it all fixed it all works right on any host...in which VST presets are implemented, which is another fun inconsistency.
|
My builds seem to work fine in Reaper but I have seen VST3 preset issues in Cakewalk by Bandlab where the last preset in the list does not load. It doesn't matter if there are 2 presets or 20, always the LAST one in the list doesn't work. It loads the default values instead of the preset values.
I haven't seen that behavior in any other DAW nor have I seen other plugins do this in CbB - so it seems something is amiss in iPlug VST3 and/or CbB. Probably the same situation you are addressing here.
One other issue I have seen with VST3 builds is that they fail Steinberg VST3 Test Host validation for Bypass issues. I searched high and wide and still don't know what is causing that. Plugins seem to work fine.
|
|
|
08-24-2019, 01:10 AM
|
#14
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
Quote:
Originally Posted by Nonlinear
My builds seem to work fine in Reaper but I have seen VST3 preset issues in Cakewalk by Bandlab where the last preset in the list does not load. It doesn't matter if there are 2 presets or 20, always the LAST one in the list doesn't work. It loads the default values instead of the preset values.
|
The bottom line is that IPlugVST3.cpp gives wrong results in a handful of places. Depending on the mix of what the host calls in implementing VST3 preset, and whether or not you tried to adjust things to make it work in one particular host, different hosts will fail in different ways. The "last preset missing" failure is a variation of this sort of thing: I already mentioned that IPlug gives the wrong numSteps value in initializing (for 32-item menu, 0-31, if passes 32. But the VST definition of numSteps would be 31). It won't matter for some hosts, depends on whether they used normalized values or not. The menu could have 32 items, just the items you set, but the host might calculate it, or it might ask IPlug to convert it to normalized. That function was missing, so in either case the host might go ahead and figure it out...OK, the last item, 31...divided by numSteps (oops, 32!), returns 0.96875. Rehydrate that back to a preset number inside Plug...0.96875 * 31 = 30 integer. Oops, you wanted 31.
You have to fix all the things I fixed. If you try to fix it here and there, you just move form one bug to another. For instance, you'll end up with the first half of the menu working fine, but the entire second half off by one (due to rounding).
You really just have to fix it, you'll never get all hosts to work right when it's being sent bad information.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 09:59 PM.
|