Reaper - plugin resizing OSX VST x64 (SOLVED)

#1

I've found a strange behaviour when internally resizing VST plugin in Reaper x64 OSX. I am able to replicate it in JuceDemoPlugin as well with a few additional lines of code. Note, that with Reaper on Windows everything works as expected.

Starting timer in plugin constructor:

startTimer (2000)

and resizing plugin inside timer callback

stopTimer();
setSize (getWidth(), getHeight() + 100);

Using standard Reaper FX window ...

- when loaded, plugin is opened and correctly resized for the first time

- if i close and reopen editor, plugin GUI is initially displayed at the correct position BUT ...

- when resize is triggered, plugin completely looses its position - it is misplaced somewhere in the middle of the Reaper FX window and only a part of it is displayed ...

- resizing Reaper FX window with a mouse reveals complete plugin, but retains misplaced position ...

I am not sure if this is Reaper's or JUCE's problem ... if plugin is opened in floating window, everything works correctly, so this one really looks like it is on Reaper's side. I've tried to load it in Nuendo 6.5 and NebulaMan (both use floating windows for plugins) and they both work ok.

Any ideas or suggestions would be greatly appreciated !!! Did anyone experience this kind of behaviour ?

Thx!

EDIT:

Resizing of AU version of the plugin works as expected, both in Reaper and Logic X.

#2

Further tests show that this misbehaviour happens with 2 consecutive setSize() calls using different plugin width.

#3

Attaching animated gif, created with LICEcap, which is showing this misbehaviour. You must usually open it in your web browser to play correctly.

You can see wrong plugin position after setSize has been called.

I've asked a question about this in a Reaper forum as well.

Thx!

#4

Here is a thread on Reaper's forum about this issue - Justin suggests that this issue should be solved in JUCE ...

http://forum.cockos.com/showthread.php?t=168914

#5

 

Justin wrote ...

The first highly problematic thing is setNativeHostWindowSizeVST():


Code:
if (NSView* hostView = (NSView*) window) {


That should check to see if hostView is the contentView, and if not, behave much differently!

Granted, I know that almost every other VST host will pass an NSView that is a contentView, so it's our fault, but we made that decision years ago and are stuck with it... :/

This probably explains some things ...

#6

Thanks, very useful! We're in the middle of summit preparation right now, but will look into this when we get chance to catch our breath!

#7

The latest reply from Justin:

There is definitely some handling I can improve in REAPER now, that is causing some of these issues. Maybe it won't require changing JUCE after all... stay tuned.

Thanks, Jules ... i'll keep you informed about Justin's progress. If he won't be able to do it,  then any improvement regarding this issue on JUCE's side will be very welcome.

#8

The latest Reaper 5.11 pre 4 OSX is now working correctly with JUCE VST2, VST3 and AU plugins. 

Additionally, Justin provided a patch, which should be applied to JUCE VST3 wrapper only in order to work correctly with the latest Reaper.

commit 37fb673b2c78ba3de4c8c9241334aa1ce845f397
Author: Justin Frankel RMBP <justin@cockos.com>
Date:   Wed Nov 18 14:43:21 2015 -0500
    VST3: handle resize for REAPER similarly to Wavelab (redux)
diff --git a/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp b/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp
index e9490b1..cd96def 100644
--- a/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp
+++ b/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp
@@ -696,7 +696,7 @@ private:
                    #if JUCE_WINDOWS
                     setSize (w, h);
                    #else
-                    if (owner.macHostWindow != nullptr && ! getHostType().isWavelab())
+                    if (owner.macHostWindow != nullptr && ! getHostType().isWavelab() && ! getHostType().isReaper())
                         juce::setNativeHostWindowSizeVST (owner.macHostWindow, this, w, h, owner.isNSView);
                    #endif
 
@@ -707,6 +707,10 @@ private:
 
                         if (getHostType().isWavelab())
                             setBounds (0, 0, w, h);
+                       #if JUCE_MAC
+                        else if (getHostType().isReaper())
+                            setBounds (0, 0, w, h);
+                       #endif
                     }
                 }
             }
#9

Great stuff, thanks for the detailed help!

I've added and pushed those changes now..

#10

Hey, I just wanted to revive this thread as we’re experiencing resizing issues on the latest version of Reaper (5.24+). These only happen on VST3. Audio Units and VST2 plugins seem to be working without issue. Basically, whenever we resize our VST3 plugin the top position gets offset inside of the reaper plugin window. Below is a gif demonstrating the bug. I’ve tried tracing to figure out the problem and it seems that every time we resize there are two calls made to “onSize()” inside of juce_VST3_Wrapper.cpp.

Interestingly, if I put a breakpoint inside of that function I can see that after the first call the plugin is correctly placed but then it’s moved to an incorrect location after the second call. It’s as if JUCE and Reaper are fighting each other regarding the top left position. You can also see this in the gif on certain frames, where the plugin goes to the correct location but then is offset a split second later.

I’ve tried putting calls to setTopLeftPosition(0,0) on the plugin inside of a timer as a hacky workaround but that had no effect. Please let me know if you have any ideas what could be causing this and what we could try to solve it (even hackily). Thanks.

c1dc180110bc465b57c7e4216a026472.gif886x762 1.14 MB

#11

Looks like the Reaper team is going to fix this bug in the next version, so this is resolved on their end. Thanks.