RTAS redraw and preset problems

Audio Plugins
1

I’m checking out Juce at the moment for porting one of my VSTs to RTAS. I’de like to use it but there seems to be some serious bugs with RTAS.
I’ve already mentioned it to Jules but i wanted to check if anyone else is getting these redraw problems with the juceDemo example:

  • it opens and draws ok first time, but if you close the plug-in window and open it again, its blank
  • when resizing, the window goes blank, till you click on it

other issue:

  • saving a preset while playing, redraws over the digi presets header or crash
  • save a preset try deleting it crash or strange redrawing

Out of interest, is anyone using 1.46 for commercial osx RTAS releases as is? No such problems with VST and AU tested on the same system.

Juce 1.46, PT 7.4.2, iMac 24, Tiger 10.4.11 and Leopard 10.5 OSX

2

no one using it for RTAS?

3

well, I use it in PPMulator! (And I do know that there are some other companies using it too, though they may not be regulars on the forum).

4

Interesting - i tried out PPMulator, no blank screens happening, some redraw
glitchyness when saving/deleting a preset, though no crashes.

What version was PPMulator compiled with Jules?
Is there anything missing from the current juceDemo RTAS code that could be causing the re-draw problem?

5

PPMulator was built a while ago, but I didn’t think much has changed since then in the RTAS wrapper. I need to update it anyway so will try it with the latest stuff and see if I can find any clues.

6

In order to avoid the redraw over the digi preset, adding

Focus(0); at the beginning of EditotCompWrapper::timerCallback()

and

RestoreFocus()

and disabling the forcedRepaintTimer does the trick

(at least it seems to)… However it does not really solve the mouse offset bugs of PT8… if anyone has an idea… the PT8 CS2 update does not seem to fix completely that bug, each time I click on a widget of the digi header , the mouse offset bug comes back.

Is this problem also present with the cocoa version ? I’m tired of protools…

7

Hi,

I am also seeing this problem (i.e. clicking on a menu in the Pro Tools plug-in header makes it draw in the wrong place). It sounds like it might be common to all JUCE RTAS plug-ins - I tried the current demo version of PPMulator and it also exhibits this problem.

I’ve tried digging into the OS specific stuff by making calls to query and track the native window locations for the component and the parent window, but everything always matches up fine.

I’m currently at a bit of a loss… Does anyone have any bright ideas?

8

As I said above, for me disabling the repaintTimer does the trick, I have even completely commented the line

//SetControlSupervisor (pluginView, parentView); //startTimer (150);

(those just below the desperate comment of Jules)

What I forgot to mention is that i have also wiped some code in DrawContents, in the ifdef JUCE_PPC (looks like it should have been changed into ifdef JUCE_MAC anyway) and replaced it by a call to peer->repaint (0, 0, wrapper->getWidth(), wrapper->getHeight()); (just like the WIN32 version)

That way, all redraw problems seem to be gone – BUT the mouse offset bug is still there with PT8 ; It makes me mad, been spending two days trying random stuff to figure a fix, nothing works reliably.

Jules, do you know if the same issue is also present with the cocoa version ?

9

The cocoa version uses a completely different method to do its drawing, so I think this should just go away…

10

just to whine a little

digi rejected my request for the RTAS API i guess saying FREE and Opensource in the request form is a bad idea.

11

Jules,

The problem does indeed go away when using the Cocoa version (I grabbed Juce from svn yesterday). A big THANK YOU! Just about everything seems to be working great, including my OpenGL component. Fantastic!

I have found a couple of problems:

  1. Text boxes: I have a timer that runs and calls repaint on the areas I have meters to redraw. That works fine, but if I try clicking a text box (I have several that are associated with sliders) to enter a value, I see the text become highlighted briefly to allow editing and then immediately become disabled to disallow editing.

  2. A crash on de-instantiation. It happens in objc_msgSend after some event handling stuff. Maybe an event handler is not being unregistered? I think I am doing everything right - I copied the code from your latest example plug-in.

Any ideas?

Thanks again!

12

Not sure about the textbox thing, though I imagine it’ll be caused by some keyboard focus stealing of some kind…

I’ve been mucking around with some messaging code in the last few days, so that might explain your shutdown bug. Try the tip again now.

13

The crash on de-instantiate is still there.

I’m also seeing crashes at runtime now. They happen when I switch to another application and then back to Pro Tools. The plug-in does not have to ever be instantiated for this to happen - all that is required to make this happen is the calls to initialiseMacRTAS and initialiseJuce_GUI that are made in the Group. For the crash to happen when switching without instantiating, I have to have both of those calls in place - remove either one and the crash no longer happens. Delete the plug-in binary and the problem goes away.

14

ok… I guess I need to do some debugging there…

15

Ah, I found the cause of the problem. Although I am only using the GUI classes, it is still necessary to call initialiseJuce_NonGUI.

16

I took a very brief look into the text box problem. I found a partial solution…

In Label::showEditor, I changed editor->setText (getText()); to editor->setText (getText(), false); to prevent the TextEditor from sending a text changed message, which causes the editor to be hidden. This keeps the text box editable.

However, although the call editor->grabKeyboardFocus(); is made, I can’t type anything into the box. I tried calling editor->setReadOnly(false); but it didn’t help. Any ideas?

17

Answering my own question, setWantsKeyboardFocus (true) had to be called. With that and the fix I mentioned in my previous message in place everything works.

18

Ok, I think that changing the setText() call like that is a good idea… Can’t think of any situations where it’d cause a problem, though it makes me a little nervous.

The TextEditor will get keyboard focus by default - which component are you talking about calling setWantsKeyboardFocus on?

19

Just checked the tip out in PT8/8 SDK and all the issues i posted
originally seem to be OK, the multi format build is cool too.

One thing i think needs adding in RTAS is the “compare” feature which should
highlight as soon as you make a change from the current preset.

btw: tried the VST and AU and the textedit control wouldnt let me enter anything

20

Jules, I just took another look. I added the setWantsKeyboardFocus to the top level component. With that call in place, I can remove the change I made to setText and it all works. So it should be safe to leave things as they are.