Plugin Crashes REAPER on macOS

[dronenb]

I compiled the plugin with:
MACOS=true BUILD_VST2=true BUILD_LV2=true BUILD_JACK=false make
I then copied the bin/wolf-spectrum.lv2 to /Library/Audio/Plug-Ins/LV2/ and the bin/wolf-spectrum.vst to /Library/Audio/Plug-Ins/VST/
When I launch REAPER and add the plugin on a track, it crashes (with both the LV2 and the VST).

I am running REAPER v6.47 and macOS 12.2.1. My other LV2 and VST plugins work fine.

[pdesaulniers]

Sadly, I don't own a mac, so I cannot help you very much with this :(

I have just updated DPF. This might help, but I'm not sure. You can pull the latest changes by running the following command:

git pull
git submodule update --init --recursive

Then, you can try compiling the plugin again.

After that, if the plugin still crashes, I suppose the next step would be to build the plugin with debug symbols (pass DEBUG=true when running make), then run the host inside a debugger such as gdb, so we can figure out which part of the plugin's code is making REAPER crash. However, this is more technical...

[dronenb]

Just did the pull and submodule update, then ran a make clean and recompiled the plugin. Same issue :(. If I get some time I will try compiling with debugging enabled and running REAPER under gdb. Until then, I guess this will remain open.

[hpfmn]

actually it also so the same for all other plugin types on macos. For some reason unknown to me the gui isn't created on macos. I also compiled DPF exmaple projects and they ran fine.

[pdesaulniers]

@hpfmn Thank you for the info!

actually it also so the same for all other plugin types on macos.

Can you run the JACK standalone on MacOS? If so, when you run the program from the command line, does it show any errors in the console?

For some reason unknown to me the gui isn't created on macos.

Just to be sure, are you loading the plugin inside REAPER? I'd be curious to know if the issue is specific to this plugin host, or if the issue can be reproduced in other hosts as well.

[hpfmn]

I'm debuging with the jack standalon and comparing it to the cairo example from DPF because I don't really know DPF's architecure. It seems at least the draw call of the spectrogram gets issued and there is also a scrolltexture. But for some reason unclear to me the window never gets created.

While stepping it also gets stuck in line 1223 of 'mac.m'

      for (NSEvent* ev = NULL;
           (ev = [world->impl->app nextEventMatchingMask:NSAnyEventMask
                                               untilDate:date
                                                  inMode:NSDefaultRunLoopMode
                                                 dequeue:YES]);) {
        [world->impl->app sendEvent:ev];

while the cairo example doesn't get stuck

[hpfmn]

Also it seems the PUGL event loop is running because I get messages like these (when running a debug build)

pugl event: Expose       0.0    0.0 2400.0  400.0
PUGL: onPuglExpose
pugl event: Expose       0.0    0.0 2400.0  400.0
PUGL: onPuglExpose
pugl event: Expose       0.0    0.0 2400.0  400.0
PUGL: onPuglExpose
pugl event: Expose       0.0    0.0 2400.0  400.0
PUGL: onPuglExpose
pugl event: Expose       0.0    0.0 2400.0  400.0
PUGL: onPuglExpose
pugl event: Expose       0.0    0.0 2400.0  400.0
PUGL: onPuglExpose
pugl event: Expose       0.0    0.0 2400.0  400.0
PUGL: onPuglExpose

[hpfmn]

If I comment out all that spectrogram stuff in Spectrogram.cpp the window appears:

void Spectrogram::draw()
{
    const float width = getWidth();
    const float scaleX = width / fBlockSize * 2;

    /*fScrollingTexture.setScaleX(scaleX);

    const int half = fBlockSize / 2;

    for (int i = 0; i < half; ++i)
    {
        const float powerSpectrumdB = fBins[i].getSmoothedValue();

        Color pixelColor = getBinPixelColor(powerSpectrumdB);

        const int freqSize = 1;
        float freqPos = i * freqSize;

        if (fLogFrequencyScaling && i < half - 1) // must interpolate to fill the gaps
        {
            const float nextPowerSpectrumdB = fBins[i + 1].getSmoothedValue();

            freqPos = getBinPos(i, half, fSampleRate);
            const int nextFreqPos = getBinPos(i + 1, half, fSampleRate);

            const int freqDelta = nextFreqPos - freqPos;

            for (int j = freqPos; j < nextFreqPos; ++j)
            {
                Color lerpedColor = getBinPixelColor(wolf::lerp(powerSpectrumdB, nextPowerSpectrumdB, (j - freqPos) / (float)freqDelta));
                fScrollingTexture.drawPixelOnCurrentLine(j, lerpedColor);
            }
        }

        fScrollingTexture.drawPixelOnCurrentLine(freqPos, pixelColor);
    }*/

   //fScrollingTexture.scroll();
}

My theory is that some events get created here and that causes to never leave the event loop or something

[hpfmn]

Ah more concrete the fScrollingTexture.scroll(); is the problem

[hpfmn]

The problem seems to be that setAbsoluteY also does a repaint. Commeting this out in dpf/dgl/src/SubWidget.cpp seems to make the plugin work:

void SubWidget::setAbsolutePos(const Point<int>& pos) noexcept
{
    if (pData->absolutePos == pos)
        return;

    PositionChangedEvent ev;
    ev.oldPos = pData->absolutePos;
    ev.pos = pos;

    pData->absolutePos = pos;
    onPositionChanged(ev);

    //repaint();
}

[hpfmn]

But now it seems to be missing the second texture. (There is always a black part between the the spectrogram)

Also clicking in the window leads to a crash/freeze

[pdesaulniers]

Interesting! This seems to be caused by memory errors. Perhaps the spectrogram is reading / writing memory out of bounds.

Is valgrind available on MacOS? I'm pretty sure a memory error detector would help diagnose the issue.

[hpfmn]

Oh sorry - the missing texture was a mistake on my side. I did add some return statements to find problematic parts and forgot to remove one of them. So the rendering of the second texture was skipped. I'll try to post a PR Workaround later today

[hpfmn]

If you click in the spectrogram also repaint() is called of part of the StatusBar setNoteText/setFrequencyText/setLeftText and it seems the freeze happens everytime repaint is called inside the onNanoDisplay of Spectrogram

[hpfmn]

I checked it is also the same with DPF filehandling example that also uses NanoVG.

[hpfmn]

I asked in DPF what the intended behaviour is

[hpfmn]

Seems to be an issue at pugl. falkTX tries to work around it and will create an issue at pugl if he doesn't succeed
until then here is my build with all repaints deactivated.
wolf-spectrum.zip

[pdesaulniers]

Oh, I see! Thank you for the detective work :)

I haven't checked, but the repaints might behave differently if we switch to the 'develop' branch of DPF (we are currently on the main branch). There are a lot of new commits on this branch: https://github.com/DISTRHO/DPF/tree/develop

If the issue can still be reproduced on the develop branch, then yes, I think we'll simply have to wait for a fix.

(With that said, I suppose it would be good idea to refactor the spectrogram's code so that the scrolling logic occurs outside of onNanoDisplay. Technically, this callback should not contain a lot of application logic; it should only contain basic rendering code.

One option could be to extract the contents of Spectrogram::onNanoDisplay() into a separate function called Spectrogram::update(), then call this new function in WolfSpectrumUI::uiIdle())

[pdesaulniers]

I've refactored the code a little bit. The UI should not call repaint inside onNanoDisplay anymore. Does this commit fix (or at least, bypass) the issue? a8f9262

[hpfmn]

Yes this fixes the issues for me :)