Plugin UI-windows displayed inside viewport

[audiostrom]

Hi
When hosting plugins (i’m using vst on windows right now), I’m trying to put the plugin editors inside a component and put that component in a ViewPort.
This way I was hoping that the plugin-uis would stay on top of the main window and that I could fit more of them in by using the scroll bars of the view port.
Anyway, what is happening is that the plugin-ui displays fine for the first plug but when I try to view a second plug I get an exception.
What is the best way to do what I want to achieve? Do I need to use some special window classes here?
The UIs show fine if I only have one open at the time.
I know that this is probably due to me doing something stupid/wrong but here is the error anyway:

[code]
Opening VST UI: The Plugin
First-chance exception at 0x0132c496 in Plugin Host.exe: 0xC00000FD: Stack overflow.
First-chance exception at 0x75603610 in Plugin Host.exe: 0xC0000005: Access violation reading location 0x00000010.

*** An Access Violation occurred in “x:\juceLib\extras\audio plugin host\Builds\VisualStudio2010.\Debug\Plugin Host.exe” :

The instruction at 0000000074D64F0D tried to read from an invalid address, 0000000000000010

*** enter .exr 000000000026D390 for the exception record
*** enter .cxr 000000000026CEA0 for the context
*** then kb to get the faulting stack

Unhandled exception at 0x75603610 in Plugin Host.exe: 0xC000041D: An unhandled exception was encountered during a user callback.[/code]

[audiostrom]

Tried to use a MultiDocumentPanel to manage the plugin GUIs, doesn’t always crash but doesn’t work either. Drawing gets messed up.
Without knowing much about the underlying code, I’m suspecting that when put inside a juce-window the plugins will get the same window handle and start fighting when drawing their editors. Would be hard to get around this I guess.
Again any ideas are welcome.

[Pca]

Plugin’s UI are handled by a system window on top of the Juce’s window… Did you really succeeded to show the plugin’s UI within a viewport? I was convinced that it’s not possible to draw partial area of a plugin UI inside a viewport…

I made several unsuccessful tries to teleport the plugin’s UI, or to zoom it within a Juce component… I’m very curious about any solution that could help :idea:

[audiostrom]

@CopperPhil Thanks for the interest. No I did not succeed in doing that. as you probably know, there are two issues.
First the plugin ui is added on top of the juce window as you say, so it overlaps other components.
Second if you have more then one ui open at once inside a Juce comp they fight each other with unpredictable results.
I would be very happy if I’m wrong as this is kind of a deal breaker for me. My application design requires that I have control over the plugin uis apart from in top-level windows.
I’ll spend the reset of the day trying to find a “hack”, if I can’t figure something out I’ll need to rethink if juce is the way to go.

[jules]

if I can’t figure something out I’ll need to rethink if juce is the way to go.

Well good luck finding an alternative that’ll work better, because there isn’t one! The plugin formats just weren’t designed for this - they all expect to have their own window, and AFAICT it’d be impossible to do what you’re talking about. Sure, you could get some formats to work - e.g. more modern OSX plugins that use NSViews, which could probably be layered successfully. But really, the only way that’ll work is to put each one in its own heavyweight window and get those heavyweight windows to do what you want.

[audiostrom]

Well good luck finding an alternative that’ll work better,

Thank you,

The plugin formats just weren’t designed for this - they all expect to have their own window

Well, true and not true, it is probably not possible in any cross-platform framework that does not use native windows.
It is however fully possible if you develop native win32 apps. I have done this. True they need a window handle but as far as i know they don’t care where this window is. The problem is that you can’t put native windows inside a juce window. This is not special to juce, I think the same limitation exists in qt for example. One would need some kind of “NativeWindowComponent” or such to do this.
Well thank you for clearing things up and giving a straight answer.

[jules]

The problem’s actually worse than that - you could bodge it for HWNDs and NSViews, but older VSTs use carbon windows which definitely can’t be embedded in a parent! The whole thing’s a can of worms, believe me! If there’d been a way to embed these things, I’d have done it, because I’d also like to be able to do that kind of thing, e.g. for tracktion.

[audiostrom]

Yes I believe you and you know way more about the mac side of things so I won’t argue with that.
I’ll just re-design my host’s ui to compensate for this limitation.
One question though is it possible for other components to live inside the plugin-ui window? like a component with some buttons and stuff next to the ui?

[jules]

It’s probably possible, and some hosts do that, but if you try making the parent window bigger than the plugin, you’re certain to hit problems with certain plugins making assumptions about their relative position/size, and may have resizing issues.

The general rule with plugins is that whatever you do, there’s bound to be at least one PITA plugin that gets broken by it!

[Pca]

The general rule with plugins is that whatever you do, there’s bound to be at least one PITA plugin that gets broken by it!

I agree 200%!!!

is it possible for other components to live inside the plugin-ui window? like a component with some buttons and stuff next to the ui?

I’m very interested about this point. I tried to do something like this to display additional information over a plugin hosted in my code. I’ve been using transparent desktop component on top of the plugin window. But my final issue was to determine the correct position over the plugin’s button… :?