Hi,
Since moving my plugin to the juce wrapper instead of my own, I have a report of an issue in the VST2 version in Cubase on OSX.
When changing in the UI the actual plugin size, the user got this.
This works fine in Reaper and Live.
In my code I only call setSize with the new size.
I don’t call setResizable as the only size changes come from my plugin itself. (no resize corner)
Does this ring a bell to someone ? (using juce develop trunk)
Thanks !
The issue can be reproduce with the Juce Gain Plugin example just by adding those lines
class GainProcessorEditor: public AudioProcessorEditor, public Button::Listener
{
public:
GainProcessorEditor(AudioProcessor &processor) : AudioProcessorEditor(processor), mBig("Push"), mLabel("Text", "Text Label") {
mBig.setClickingTogglesState(true);
mBig.addListener(this);
addAndMakeVisible(&mBig);
addAndMakeVisible(&mLabel);
mLabel.setColour(Label::textColourId, Colours::white);
setSize(200, 200);
}
void buttonClicked (Button * button) override
{
if (button->getToggleState())
setSize(200, 400);
else
setSize(200, 200);
}
void resized() override
{
mBig.setBounds(0, 0, 100, 50);
mLabel.setBounds(0, getHeight() - 50, getWidth(), 50);
}
TextButton mBig;
Label mLabel;
};
and this
AudioProcessorEditor* createEditor() override { return new GainProcessorEditor (*this); }
Thanks for putting together a code example, that’s really helpful. I’ve put together a patch which should fix this issue, which I’ll push once it has been reviewed and tested a bit more thoroughly.
I’ve just pushed this change, which appears to resolve the issue:
Please try it out and let us know if you encounter any further problems.
It fixes the main plugin issue, but it looks like something else has been broken in the meantime.
The menu is called like that
m.showAt(componentToAttachTo, 1, 100, 1, 20);
Thanks for reporting. I can reproduce the issue, and am currently investigating a solution.
This patch should fix the issue:
So far, so good.
Thanks !
Maybe something related
scale increase the audio processor editor size by the ratio and add a transform scale into the main widget (not the audio processor editor itself)
Can you provide some more details, please? It’d be useful to know how this editor is configured. Do you see the same issue in any of the JUCE demo plugins?
Is the behaviour you’re seeing in that gif definitely new, or was it also present before the NSViewComponentPeer changes (e.g. in commit ec43c7f61c)?
I tried modifying the DSPModulePluginDemo with a similar setup and it seems to work fine, for the most part. Jumping from 10x scaling down to 1x scaling sometimes fails to refresh the view properly, but I’m seeing the same behaviour on ec43c7f61c. Other than that, the window size and scale update appropriately.
diff --git a/examples/Plugins/DSPModulePluginDemo.h b/examples/Plugins/DSPModulePluginDemo.h
index 4dd0f8d870..d931cbf315 100644
--- a/examples/Plugins/DSPModulePluginDemo.h
+++ b/examples/Plugins/DSPModulePluginDemo.h
@@ -1477,12 +1477,11 @@ private:
};
//==============================================================================
-class DspModulePluginDemoEditor : public AudioProcessorEditor
+class DspModulePluginDemoEditor : public Component
{
public:
explicit DspModulePluginDemoEditor (DspModulePluginDemo& p)
- : AudioProcessorEditor (&p),
- proc (p)
+ : proc (p)
{
comboEffect.addSectionHeading ("Main");
comboEffect.addItem ("Distortion", TabDistortion);
@@ -1529,9 +1528,6 @@ public:
labelEffect.attachToComponent (&comboEffect, true);
updateVisibility();
-
- setSize (800, 430);
- setResizable (false, false);
}
//==============================================================================
@@ -2027,11 +2023,46 @@ private:
JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (DspModulePluginDemoEditor)
};
+struct Editor : AudioProcessorEditor
+{
+ explicit Editor (DspModulePluginDemo& proc)
+ : AudioProcessorEditor (proc),
+ widget (proc)
+ {
+ addAndMakeVisible (widget);
+ addAndMakeVisible (textEditor);
+ updateScale();
+ setResizable (false, false);
+
+ textEditor.onReturnKey = [this]
+ {
+ scale = textEditor.getText().getFloatValue();
+ updateScale();
+ };
+ }
+
+ void resized() override
+ {
+ widget.setBounds (getLocalBounds() / scale);
+ textEditor.setSize (80, 24);
+ }
+
+ void updateScale()
+ {
+ widget.setTransform (AffineTransform::scale (scale));
+ setSize (scale * 800, scale * 430);
+ }
+
+ DspModulePluginDemoEditor widget;
+ TextEditor textEditor;
+ float scale = 1.0f;
+};
+
struct DspModulePluginDemoAudioProcessor : public DspModulePluginDemo
{
AudioProcessorEditor* createEditor() override
{
- return new DspModulePluginDemoEditor (*this);
+ return new Editor (*this);
}
bool hasEditor() const override { return true; }
It seems to happen only for 200% scale in my case so maybe something that happen only if Juce window is bigger than the screen size
I don’t have any setResizeLimits in my code
and don’t call setResizable
I compute the original width and height in my code given the actual width and height with the previous scale.
Looks like getWidth and getHeight is in that case limited by the screen size, so maybe you cannot have a plugin size bigger than the original one. hence my issue when getting back to smaller scaling
void UVIWorkstationUI::SetScaling(float scaling)
{
float previousScaling = UIResourceManager::LocalScaleFactor;
UIResourceManager::LocalScaleFactor = scaling;
mpWrapper->setTransform(juce::AffineTransform::scale(scaling));
// default size
float w = getWidth() / previousScaling;
float h = getHeight() / previousScaling;
setSize(w * scaling, h * scaling);
}
I can fix my code but it should have worked no ?
Is there any way you can test whether this was an issue before the recent NSViewComponentPeer changes? If it was, then I’d be inclined to say that this is a bug in your code. If this is a new regression, then I’ll attempt to fix it in JUCE.
just add
float previousScale = 1.0f;
setSize(800, 430)
previousScale = scale
scale = textEditor.getText().getFloatValue();
updateScale();
and
void updateScale()
{
widget.setTransform (AffineTransform::scale (scale));
setSize (scale * getWidth() / previousScale, scale * getHeight() / previousScale);
}
I can fix my code in UVIWorkstation case but this will means this will break Falcon which has a resizable GUI with scaling on top of that
Alright, I’m seeing the same behaviour before the NSViewComponentPeer changes, so this is not a new regression.
It looks like in the AAX wrapper, resize requests to the host may fail. In this case, the editor is reset to the last known-good size. We don’t have a dedicated way to signal this failure in the JUCE API at the moment, but it’s quite easy to check whether the size actually changed to the expected value after calling setSize:
void updateScale (float newScale)
{
const auto oldScale = std::exchange (scale, newScale);
const auto oldBounds = getLocalBounds();
setSize (scale * getWidth() / oldScale, scale * getHeight() / oldScale);
// Check if the resize succeeded
if (getLocalBounds() == oldBounds)
{
// The resize failed, revert to the previous scale
scale = oldScale;
resized();
}
else
{
widget.setTransform (AffineTransform::scale (scale));
}
}
To be clear, the AAX wrapper is refusing to accept the requested size. There’s nothing we can do in JUCE to force the requested editor size. If there’s a chance that you’ll request a very large editor size, you should add some checks in your code to ensure that the new size is what you expect.
ok good to know.
Thanks !
