Accessing Plugin GUI without event loop


#1

Hey all,

I’m investigating JUCE as an option for a project I’m working on that has a need to host and display VST3 and AudioUnit plugins and this seems like a really promising option.

My question is that from looking around at the code and examples I would need to include all of JUCE’s GUI and event-loop framework in order to get to the point where I can display the gui window of a plugin i’ve instantiated. Is this true?

The project I’m working on maintains it’s own event loop and I’d really like a way to display the UI of a plugin in one of my app’s windows. Has anyone done something like this before?

Keep up the good work! This looks like a really cool platform.

Thanks,

-Dave


#2

No, it doesn’t need to be in charge of the event loop - obviously if you’re running a plugin then the host does the event loop. No guarantee that it’ll all work OK in any random app environment that you choose to throw at it, but I think that as long as you use a ScopedJuceInitialiser_GUI and don’t create an Application object, then everything is likely to work.


#3

Ah I think ScopedJuceInitialiser_GUI was the piece of the puzzle I was
missing.

Thanks so much!


#4

Ah I’m still having trouble.

I can get the editor from the plugin instance, and the class I’m instantiating the plugin in has a reference to ScopedJuceInitialiser_GUI but I can’t get any GUI to display.

Right now I’m ignoring the plugin aspect of the problem entirely and I’m just trying to get ANY Juce GUI component to display.

Is it up to me to create a native window to attach the editor’s window handle from if i’m not using the JuceApplication class/ START_JUCE_APPLICATION macro?

Or is it feasible that I could use a DocumentWindow or something like that to attach the editor too when I have a reference to ScopedJuceInitialiser_GUI.

If the latter doesn’t sound like the complete wrong approach then I’ll put the legwork into finding the issue with my environment, I just don’t want to start myself down a bad path!

The class I’m testing with is something similar to this:

class PluginWindow {
public:
  PluginWindow() {
    this->window = new vstjs::MainWindow("Test Window");
    this->window->getWindowHandle();
  }
  ~PluginWindow() {}

private:
  ScopedJuceInitialiser_GUI libraryInitialiser;
  ScopedPointer<MainWindow> window;
};

Where MainWIndow is yanked from one of the examples:

class MainWindow: public DocumentWindow
{
public:
  MainWindow (String name)  : DocumentWindow (name,
    Colours::lightgrey,
    DocumentWindow::allButtons)
  {
    setUsingNativeTitleBar (true);
//    setContentOwned (createMainContentComponent(), true);
    setResizable (true, true);

    centreWithSize (getWidth(), getHeight());
    setVisible (true);
  }

  void closeButtonPressed() override
  {
    // This is called when the user tries to close this window. Here, we'll just
    // ask the app to quit when this happens, but you can change this to do
    // whatever you need.
    JUCEApplication::getInstance()->systemRequestedQuit();
  }

  /* Note: Be careful if you override any DocumentWindow methods - the base
     class uses a lot of them, so by overriding you might break its functionality.
     It's best to do all your work in your content component instead, but if
     you really have to override any DocumentWindow methods, make sure your
     subclass also calls the superclass's method.
  */

private:
  JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (MainWindow)
};

#5

Hard to say what’s going on without knowing what the host is doing or being able to debug it… You should probably just step into the code in ComponentPeer and see how far it gets towards creating a window.


#6

Looks like my ComponentPeer is getting immediately destroyed. I should be able to figure it out from here. Really appreciate your help!