Issues in exported AAX plugins: drawing panels and buttons, sliding a panel

[gorangrooves]

@Christoph-Hart I've been meaning to do the Git, but am not familiar enough with it and am pressed for the time.

I've restructured the project significantly, so I am not sure Git would be of much help other than telling me that everything is different now I used to have all sections of the project on the onInit. Now, they are split into files integrated with include.

I guess this will be a trial-and-error process. If I can at least get to the bits of code that are misbehaving, you could provide the clues as to why. The maddening thing is that it all works in HISE, compiled app, and VST, so there is no indication of anything being wrong.

[d.healey]

@gorangrooves said in Issues in exported AAX plugins: drawing panels and buttons, sliding a panel:

Now, they are split into files integrated with include.

That will help. Comment out all of the includes. Then re-add them one by one until the problem happens.

[gorangrooves]

@d-healey Yes, I'll do that.

[Christoph Hart]

@gorangrooves Hard to say what exactly is causing that but I would scan everything related to repaint() calls or when you start / stop any timers.

[gorangrooves]

@Christoph-Hart Yeah, I'll turn off things that use timers, see if other sections improve, and go from there.

[gorangrooves]

@Christoph-Hart @d-healey Alright, guys. After going down every single rabbit hole, disabling everything in my plugin until there was almost nothing left, while still having the same issues, I came upon a discovery.

I closed the GUI in Pro Tool and re-opened it, and bam, my sliding panel was working!

I then recompiled my plugins with all the features and loaded them into PT. When the GUI comes up at the start, it is messed up, and things don't work, but as soon as I close it and reopen it, everything is perfect. WTF?!

There is only one more thing I can think of that I can try: make sure all my LAF scripts are at the very end.

[gorangrooves]

@Christoph-Hart I moved the LAF to the end of the plugin, but that didn't change anything.

BTW I have these warnings with the current HISE version.

Interface: Skipping changed() callback during onInit for stopBtn
Interface: WARNING: time between abort checks 502 ms) is above timeout (500 ms).
goto @0
Interface: WARNING: time between abort checks 502 ms) is above timeout (500 ms).
goto @0
Interface: Skipping changed() callback during onInit for autoplayBtn
Interface: Skipping changed() callback during onInit for AddChSlider1
Interface: Skipping changed() callback during onInit for PillButton4
Interface: Skipping changed() callback during onInit for dawTempoBtn

Sometimes, the "time between abort checks" is greater, like 700ms.

Could that have anything to do with it?

[Christoph Hart]

@gorangrooves The skip warnings are not critical, they are just reporting what went previously unnoticed.

Are you using a background thread in HiseScript? The other warning should fire only when you have a background thread where you don't check if the thread should exit regularly.

[gorangrooves]

@Christoph-Hart Yes, there is a background thread for the MIDI loop browser.

So, I disabled LAF for the plugin, but the results were still the same in PT. Certain things are not working until the GUI is closed and reopened.

What does all this mean? Where do we go from here?

[gorangrooves]

I managed to strip the plugin to the bare bone and get those components working. Now, I'll enable one by one, compile, load...rinse, repeat.

[Dan Korneff]

@gorangrooves that sounds like my past 4 days
Fun!

[gorangrooves]

@Dan-Korneff I hear you, bro! I made good progress today, but I am exhausted. Hoping to nail it tomorrow.
I hope you are managing to hunt down the bugs messing with your project.

[ustk]

@Christoph-Hart @gorangrooves I remember putting a shouldAbort check at every sensible places in the MIDI browser but I might have missed one...
The issue with placing everything in separate scripts is that you cannot always have a really good separation (well, depending on your coding style)
For instance I always have a declaration script at the very beginning because you can use a component in different places, and if it's not declared already you get an assertion...
Unless I am very sure the component in question won't be accessed from elsewhere so I can declare it in the corresponding namespace of that script, it goes to the declaration one. This is just an exemple as many things can go wrong.

Another thing is to have a namespace per script to keep things tidy, so don't forget to append the namespace to any external call of a variable/function.

[gorangrooves]

@ustk I've been following a similar approach, namely declaring components in couple of scripts at the top, with the functions in other scripts. Yesterday, I managed to narrow down one issue to a script, but there is still one more pending to be discovered today. Then, I'll have to make sense as to why they are causing the issues and how to get around that.

[gorangrooves]

@Christoph-Hart I disabled everything in my plugin other than the main declarations, paths, and LAF.
I even disabled fonts, synth defer callbacks. I have nothing else to disable.

There are 2 issues.

One has something to do with one of my scripts, resulting in onNoteOn not working and the expanding panel not expanding. I'll get to that in a little bit.

The second issue has to do with Pro Tools not displaying anything that is painted using paths. It displays simple elements created using the paint routine but no SVG paths. My previous version of plugin didn't use any paths, hence the reason why it displays ok in PT.

When I use your test script to repaint everything, after a few seconds, all elements show up. So, my conclusion is that there is a bug with painting SVG paths in PT on init.

Can you replicate this issue on your end?