Hi,
we are having an issue with the plugin sliders response (moving them with the mouse) when in Logic 10.7.0
In previous versions of Logic and other DAWs this issue does not occur.
The issue occurs on intel Macs (Big Sur/Monterey) and on M1 Macs when Logic is ran under Rosetta.
When Logic 10.7.0 runs natively on M1, the sliders response is normal.
Do you have any idea what may be causing this?
Thanks much!
Have you tested any non-JUCE plugins under Logic 10.7? Do they behave in the same way?
Yes, other plugins like U-He plugins, FabFilter, Voxengo for example, are ok.
Plugins that use Juce like Valhalla are also ok.
The problem appears only with our plugin on Logic 10.7.0
Previous versions of Logic are not showing this behavior.
Are you able to reproduce this in any of the JUCE examples? In order for us to investigate, we’ll need to be able to reproduce the issue here.
It might be worth testing with a sampling profiler such as Xcode Instruments. If moving a slider is triggering time-consuming operations, the profiler might be able to show where that time is being spent.
I just tried it with a Juce example using Juce 6.1.2 and it behaves ok.
So, it seems to be only with our plugin. It is strange that the issue happens only with Logic 10.7.0 though
If you are using custom elements, you need to ensure you’re sending a gesture start on mouse down and a gesture end on mouse up, and just sending parameter changes on slider movement. If you hit Logic 10.7 with rapid gesture start/end messages it slows down badly. Might not be this if you’re just using standard sliders, but if you’ve customised things, could be that.
Thank you for the suggestion. It seems that it does not have to do with that because the sliders are standard. The issue occurs only on Intel Macs or when under Rosetta on M1, on LP10.7
We are looking to see what is causing it. It seems like some sort of midi loop.
When controlling the sliders from Logic’s quick controls they work fine.
When moving them with the mouse or via a midi controller they are slow/stepped.
Hi guys,
we did a simple test project using JUCE classes from the examples and when we control the slider with midi, the problem appears (sluggish/jumpy movement of the slider).
Attached is the code Source.zip (6.6 KB)
#include "PluginProcessor.h"
#include "PluginEditor.h"
//==============================================================================
TestAudioProcessorEditor::TestAudioProcessorEditor (TestAudioProcessor& p)
: AudioProcessorEditor (&p), audioProcessor (p)
{
slider = std::make_unique<juce::Slider>();
slider->setSliderStyle(juce::Slider::SliderStyle::Rotary);
slider->setBounds(0, 0, 200, 200);
attachment = std::make_unique<juce::AudioProcessorValueTreeState::SliderAttachment>(p.getState(), "test", *slider);
auto devices = juce::MidiInput::getAvailableDevices();
for (auto& device : devices)
{
if (device.name == "MYMIDIDEVICE")
{
deviceManager.setMidiInputDeviceEnabled(device.identifier, true);
break;
}
};
deviceManager.addMidiInputDeviceCallback("", this);
addAndMakeVisible(*slider);
setSize (400, 300);
}
TestAudioProcessorEditor::~TestAudioProcessorEditor()
{
}
//==============================================================================
void TestAudioProcessorEditor::paint (juce::Graphics& g)
{
// (Our component is opaque, so we must completely fill the background with a solid colour)
g.fillAll (getLookAndFeel().findColour (juce::ResizableWindow::backgroundColourId));
g.setColour (juce::Colours::white);
g.setFont (15.0f);
g.drawFittedText ("Hello World!", getLocalBounds(), juce::Justification::centred, 1);
}
void TestAudioProcessorEditor::resized()
{
// This is generally where you'll want to lay out the positions of any
// subcomponents in your editor..
}
void TestAudioProcessorEditor::handleIncomingMidiMessage(juce::MidiInput * source, const juce::MidiMessage& message)
{
auto value = message.getControllerValue();
juce::MessageManager::callAsync([this, value]
{
auto parameter = audioProcessor.getState().getParameter("test");
parameter->beginChangeGesture();
parameter->setValueNotifyingHost(parameter->getNormalisableRange().convertTo0to1(value));
parameter->endChangeGesture();
});
}
Does it improve if you remove the change gestures? I am guessing it will as I think that’s where the problem is.
Yes, indeed if we remove the change gestures it’s ok. But what is the alternative here?
Without the change gestures the DAW will not be receiving the value change.
I don’t think there is an alternative really, with a slider you can begin and end a gesture on mouse down/up but you have no way to know when the end of the MIDI reception is going to be in a similar motion from the user’s side so you’ll send Logic more gesture start/end events than it seems to be happy with in 10.7.
In an ideal world somebody has let Apple know about this change in behaviour related to gesture behaviour and they’re working to revert to how things used to be. No idea if that’s the case or not!
There is also the fact that it happens only on Intel Macs or when under Rosetta on M1.
Does this mean that LP 10.7 uses different code for Intel Macs or when under Rosetta?
Btw, when commenting out this only //parameter->endChangeGesture(); (not the beginChangeGesture() )
the movement is a bit better.
But, at the end the question is,
why when using the mouse is ok, and when using MIDI to control the slider, there is this problem?
Logic is not aware we are using MIDI, because the controller is linked straight on the plugin.
Here is a video showing the behavior
It’s OK when using the mouse because you only send a gesture start/end when the mouse is clicked or released (i.e. mouse up / down). All the changes made when the button is down will not send a gesture. Compare to your MIDI which is sending a gesture every time there is an update from the MIDI source.
About the native vs Rosetta situation, it’s maybe to do with the de-coupling that we now have on AUs in Logic where sometimes we run in a separate process.
Our plugin relies heavily on using midi so does this mean we have implement a new method of sending the updated values to the DAW, or is this something the Juce will update to accommodate the change in LP 10.7?
I was able to reproduce the problem in Logic 10.7.0 running on an Intel Macbook Pro on macOS 11.6, I can also confirm that the issue isn’t present in older versions of Logic (I tested 10.5) or in other DAWs such as Reaper or Live 11.
It looks to me like this is a bug in the new version of Logic since we are simply calling AUEventListenerNotify() for the parameter begin/end change gestures and nothing has changed in the JUCE AU wrapper code recently that may be causing this. My best guess is that one of the parameter listeners in Logic is doing something time consuming and is flooding the message queue which is causing the lag/slowdown in the editor rendering. I’d like to confirm this by putting together a minimal reproducible example AU that doesn’t use any of the JUCE wrapper code before submitting a bug report to Apple. However, it’s unlikely that I will have time to do this for a week or so due to ADC.
It’s certainly not anything due to recent changes in Juce, I’ve observed this problem in plug-ins based on Juce 5.4.5, so worth dropping a report to Apple.
Hi Ed,
thanks much for looking into this. What is puzzling to me is that on M1 natively LP 10.7 we don’t see this issue.
I also would expect this to be happening to midi controlled parameters of plugins in LP 10.7 on Intel Macs (or Rosetta) as well, but is not the case.
It seems that the bug is affecting when on Apple Silicon as well.
I have just ran the test project on M1 LP 10.7 natively and although the slider is behaving ok (in contrast when is under Rosetta), the automation parameter on Logic is behaving slow
