ISwitchControl bitmap getting out of sync on AAX

[Nonlinear]

Problem with ISwitchControl running in Pro Tools (AAX). Clicking on a switch when the transport is running changes the control’s state (toggles it) but the bitmap SOMETIMES doesn’t change - causing the bitmap and control state to become out of sync.

This does not happen when playback is stopped nor in VST, VST3 or AU versions. There's obviously an issue with Draw called in the ISwitchControl but I don’t know why it only happens in Pro Tools and only on Mac OS.

I made a workaround by calling parameterIdx->Redraw() for the control in OnParamChange(). It works but is it “safe” to force a redraw from there? I would rather fix the problem with ISwitchControl if possible.

Anyone else come across this?

TBPro pointed me to the cause - it's in iGraphics.cpp - so it could actually be a latent problem in all formats. Every occurrence of pControl->Draw(this) in the IGraphics Draw() method needs to be immediately followed with pControl->SetClean(). In other words they have to form a pair. I found that pControl2 (in a loop through all controls) had no SetClean() at all so I added it. With these changes the iSwitch sync problem is solved. Could be that other plugin formats have faster/different GUI threads so this issue only appeared in Pro Tools, IDK.

[Nonlinear]

Originally Posted by Nonlinear

TBPro pointed me to the cause - it's in iGraphics.cpp - so it could actually be a latent problem in all formats. Every occurrence of pControl->Draw(this) in the IGraphics Draw() method needs to be immediately followed with pControl->SetClean(). In other words they have to form a pair. I found that pControl2 (in a loop through all controls) had no SetClean() at all so I added it. With these changes the iSwitch sync problem is solved. Could be that other plugin formats have faster/different GUI threads so this issue only appeared in Pro Tools, IDK.

Nope - still a problem in AAX. Everything works fine when transport is stopped but if transport is running buttons don't always update correctly - ISwitch status changes but the associated bitmap SOMETIMES does not causing the displayed value and actual value to become out of sync.

I can FORCE a redraw of the control in OnParamChange() - and it works - but why do I need to do that? (It's a "band aid" I'd rather not have to use)

Any other suggestions? Again, it works fine everywhere else - just not AAX/Pro Tools and only on Mac (works fine in Windows).

[Nonlinear]

UPDATE: It seems I found the fix. In addition to TBPro's code changes I made this additional change in IControl.cpp:

void IControl::SetClean()
{
 //  mDirty = mRedraw;
  mDirty = true;
  mRedraw = false;
}

So it seems you can't rely on mRedraw being true when entering this code. Forcing it true here fixed the problem in Pro Tools on Mac. Also checked good in Reaper and Logic Pro.

[Tale]

But doesn't that cause the GUI to be redrawn constantly (presumably at only 24 FPS, but still)?

[Nonlinear]

Originally Posted by Tale

But doesn't that cause the GUI to be redrawn constantly (presumably at only 24 FPS, but still)?

I didn't see a performance hit in Pro Tools after making these changes so I didn't think to check. But now I have and, yes, "SetClean()" is getting called constantly. Maybe it has been doing this all along, IDK, I wasn't looking for it. I update my GUI on every block (meters, etc.) so maybe the performance hit is being masked by those updates. I temporarily disabled my GUI update code in the processing blocks but SetClean() is still being called from somewhere.

Ugh, OK, so there must be a "root cause" fix for the issue. It's strange - and perhaps a clue - that I'm only seeing this problem in Pro Tools and only on Mac. I've looked through iPlug's Mac and AAX -specific files but don't see a possible cause. Debugger struggles for some reason in Pro Tools so I'm having a tough time tracing the steps there - further complicated by the fact that it's an intermittent problem.

BTW - the iGraphics.cpp code looks a little funny to me too. It checks if(mStrict) and mStrict appears to always be true - which I believe means it constantly redraws. Is that why SetClean() keeps getting called? Also, the function itself seems to be recursive in that it calls pControl->Draw() from inside the Draw() function. Isn't this an endless loop? I don't understand what's going on here...

[Tale]

Actually pGraphics->Draw() calls pControl->Draw(), so there is no recursion.

Anyway, this is how it should work: If you change a parameter, then the control is marked as dirty by calling pControl->SetDirty(). The next time pGraphics->IsDirty() is called it will detect that one or more controls are dirty by checking IControl->IsDirty(). If dirty then pGraphics->Draw() will draw controls by calling pControl->Draw() for each of them, and then mark the control as clean by calling pControl->SetClean(). Then the next time pGraphics->IsDirty() is called no controls will be dirty, and so nothing will be redrawn until there is another change.

Now, if you set mDirty to true in pControl->SetClean(), then pGraphics->IsDirty() will always return true, and so pGraphics->Draw() will be called each and every time, by default at 24 FPS.

BTW, you can disable strict drawing by calling pGraphics->SetStrictDrawing(false), but by default strict drawing is enabled.