InterProcessConnection from plugin on windows

Audio Plugins
1

I’m trying to access InterprocessConnectionServer, running on a separate juce GUI application from my VST plugin running on a DAW (Reaper) using InterprocessConnection on Windows.

However, connectToSocket called on the plugin/client side always returns false.

It works properly when I run the same program on Mac or when I try to connect the server from a console application using InterprocessConnection on Windows.

What I found using the debugger is

returns false when I try to access from a plugin but returns true when I access from a console app.
But I’m not sure why the locking is not successful on a plugin and successful on a console app.

I would appreciate any help on this topic. Thank you.

2

I just simply tried this on a AudioPluginAudioProcessor’s constructor and the locking failed.

AudioPluginAudioProcessor::AudioPluginAudioProcessor()
: AudioProcessor (BusesProperties()
                         .withInput  ("Input",  juce::AudioChannelSet::stereo(), true)
                         .withOutput ("Output", juce::AudioChannelSet::stereo(), true))
{
    const auto lock = juce::ScopedTryLock(criticalSection_);

    if(lock.isLocked())
    {
        DBG("locked successfully");
    }
    else
    {
        DBG("lock failed");
    }
}
3

However, if I call directly TryEnterCriticalSection, it succeeds.

AudioPluginAudioProcessor::AudioPluginAudioProcessor()
: AudioProcessor (BusesProperties()
                         .withInput  ("Input",  juce::AudioChannelSet::stereo(), true)
                         .withOutput ("Output", juce::AudioChannelSet::stereo(), true))
{
    InitializeCriticalSection(&cs_);

    if (TryEnterCriticalSection(&cs_)) {
        std::cout << "Entered critical section" << std::endl;
        LeaveCriticalSection(&cs_);
    } else {
        std::cout << "Failed to enter critical section" << std::endl;
    }

    DeleteCriticalSection(&cs_);
}
4

Are you absolutely sure nothing else has the critical section? For example if you change the example to take a local critical section, does it still fail?

AudioPluginAudioProcessor::AudioPluginAudioProcessor()
: AudioProcessor (BusesProperties()
                         .withInput  ("Input",  juce::AudioChannelSet::stereo(), true)
                         .withOutput ("Output", juce::AudioChannelSet::stereo(), true))
{
    juce::CriticalSection localCriticalSection;
    const auto lock = juce::ScopedTryLock(localCriticalSection);

    if(lock.isLocked())
    {
        DBG("locked successfully");
    }
    else
    {
        DBG("lock failed");
    }
}
5

Thank you for your reply.

I just copied your code and tested. my debugger stops at else clause. so yes, it still fail.
My environment is Win 11. Reaper 6.81. I’m instanceating just one plugin instance on the session.

Screenshot 2023-12-06 181106
Screenshot 2023-12-06 181106985×607 54.5 KB

6

OK it seems likely something very odd is going on here. A couple of questions that you may or may not have answers too but could really help us.

  • You don’t mention the JUCE version, does this happen on the latest version on the develop branch?
  • Can you reproduce this using one of the example plugins?
  • Just to understand the issue more does this happen if you do the same thing in the editors constructor rather than the processor?
  • Can you update Windows 11 or have you recently updated Windows 11?
  • Have you tried this on Windows 10?
  • Have you tried any different machines?
  • Have you tried a newer version of Reaper?
  • Does this only happen on Reaper? if you have any other DAWs it might be nice to eliminate this.

Thanks.

7
  • Juce Version
    7.0.9
  • Can you reproduce this using one of the example plugins?
    I’m testing it with the modified version of the example plugin I found under JUCE/examples/CMake/AudioPlugin
  • Just to understand the issue more does this happen if you do the same thing in the editors constructor rather than the processor?
    Yes
  • Have you tried this on Windows 10?
    No
  • Have you tried any different machines?
    No, unfortunetely I don’t have any other machines at home.
  • Have you tried a newer version of Reaper?
    No
  • Does this only happen on Reaper?
    It happens also on Nuendo 10.3
1 Like
8

@anthony-nicholls

Today I also tried on another Win 11 machine (note both my machine and another machine are using AMD CPU, I’m not sure if this is relevant).

On the other machine, I used the newer version of Reaper 7.0.6 and I can still reproduce the symptom. I cannot lock the thread.

1 Like
9

Thanks, that’s interesting we haven’t managed to reproduce the issue yet.

10

If you change this line:

const auto lock = juce::ScopedTryLock(localCriticalSection);

to

const juce::ScopedTryLock lock (localCriticalSection);

do you get a different outcome?

I wonder if the initialization with “=” might result in the ScopedLock on the right of the = going out of scope when you copy it into the “lock” variable (just guessing, I don’t remember exactly what the standard says in this case).

11

This crossed my mind too, the Curiously recurring C++ Bugs talk came to mind, but I couldn’t seem to reproduce an issue between the two styles myself. Definitely worth trying to eliminate any doubt though.

12

Also the assignment operator should be both private and deleted so I assume in this case the assignment operator is never actually called?

14

Tried that but it produces the same outcome

Screenshot 2023-12-07 110847
Screenshot 2023-12-07 1108471567×660 82.8 KB

1 Like
15

Installed Ableton Live 11 trial and tested on it. locking failed. so it probably doesn’t matter which DAW I use.

1 Like
16

Tested on Windows 10 machine using Intel CPU, I can still reproduce the symptom.

17

@anthony-nicholls @yfede

Hey, I guess I found the cause. sorry, it’s my fault.
I changed just one thing from the example plugin, and this produced the issue.

target_compile_definitions(CriticalSectionTest
PUBLIC
VST3_AUTO_MANIFEST FALSE
JUCE_WEB_BROWSER=0
JUCE_USE_CURL=0
JUCE_VST3_CAN_REPLACE_VST2=0)

If I remove the line and let juce produce the moduleinfo, it worked properly.
I thought this file (moduleinfo) just lets the DAW know the property of the plugin without loading the plugin. but seemingly, it influeves how the plugin is treated by the DAW… ?

18

It’s nice to know things are working for you again but that still seems very surprising!

19

@chikashimiyama just to be completely sure can you set it to false again and see if you can still reproduce the issue?

20

Yes, I can reproduce.
VST3_AUTO_MANIFEST TRUE → succeeded
VST3_AUTO_MANIFEST FALSE → failed
VST3_AUTO_MANIFEST TRUE → succeeded

21

Also If I set VST3_AUTO_MANIFEST TRUE and remove moduleinfo file manualy from the .vst3 plugin. It still succeeds.