VSTGUI Help!

[kirsty roland]

Hi Guys

After spending/wasting two weeks of my life with VSTGUI and not getting it to work properly and
then finding it can't do what I need, I think I'm about ready to shoot myself in the face with a bazooka.

What I would really like is to make my interface using only Window GDI/GDI+ but I can't find any
info on the web. Does anyone have experience of/or can point me to some help on how to initialise such
a window and get me to the stage where i can at least draw to the hdc, without all this VSTGUI nonsense.

Thanks
Kirsty

[matt42]

I think I'm about ready to shoot myself in the face with a bazooka.

I am well aware of this feeling I haven't touched VSTGUI for many years due to this. These days I use JUCE, but some years ago I wrote my own framework. So my memory is stretching back somewhat, and this reply might/will be thin on details.

To create your GUI/editor class you need to inherit from the base editor class. In VST2 it is AEffEditor. It only has a few functions, such as open(), close() and whatnot. On a call to open you are passed a HWND (you supply the dimensions with getRect(), but the host creates the plugin window) and should use that to get an HDC for drawing with GDI/GDI+.

[matt42]

Please delete. Double post

[S0lo]

I happen to have gone through your same steps through the last 3 or 4 years. The first thing I would say is try your best not to waste your time on GDI+ because it is no longer hardware accelerated in Windows 7 and above, although it has great capabilities. I learned that the hard way. Infact there doesn't seam to be a single document which is crystal clear about it's hardware acceleration support. But as far as I can tell, it most probably not any more.

You'll not notice the slowness if your drawing like once in a while. But for continuous drawing like meters, scopes or even cable redrawing because of updated graphics underneath...etc it sucks. What complicates things is that this kind of CPU usage is not shown in your DAW CPU usage meter!! because it's part of the GUI thread which has lower priority and will never interfere with audio, but it will make your GUI and probably DAW sluggish.

The new recommended platform for complex fast graphics is Active2D. And I believe VSGUI 4 supports that. But if your requirements are only like simple drawings and copying of bitmaps/knobs movement. Then you can still live with only GDI (Not GDI+) plus the AlphaBlend() function. These are lite enough on the CPU. Thats what I ended up doing my self any way for the most part. Albeit, I'm still stuck with GDI+ for a few things, looking forward for the day to get rid of it.

[mystran]

If I recall correctly, GDI in general lost all hardware acceleration in Vista. In Windows 7 they added some of it back, but I think it's basically limited to some basics like BitBLT() and maybe AlphaBlend() and even with these probably only the common DIB formats (ie. basically the stuff you can give GPU as a texture).

[kirsty roland]

If you can help I think this is where I'm going wrong.
I can't seem to get a valid handle to the device context from the HWND *ptr

Code: Select all

bool SynthGUI::open (void *ptr)
{
	// !!! always call this !!!
	AEffGUIEditor::open (ptr);

	// Set up window size
	int WinWidth = 640;
	int WinHeight = 480;
 
	CRect size (0, 0, WinWidth, WinHeight );

	// Set up window frame with rect size
	CFrame* lFrame = new CFrame (size, ptr, this);
	frame = lFrame;

	// ************************************************************
	// This compiles ok but does not draw the red line on the frame
	// ************************************************************	
	// Get WinDC from AEffGUIEditor *ptr	
	HDC hDC = CreateCompatibleDC( (HDC)ptr );

	// Create a red pen
	HPEN pen = CreatePen( PS_SOLID, 1, RGB(255,0,0) );
	HGDIOBJ old_pen = SelectObject( hDC, pen );

	// Draw diagonal line
	MoveToEx(hDC, 0,0, 0 );
	LineTo(hDC, WinWidth,WinHeight);

	// Delete pen
	SelectObject( hDC, old_pen );
	DeleteObject(pen);

	return true;
}

I can stick to GDI for any regular updates and only use GDI+ for the static eye candy.

Kirsty

[mystran]

Assuming this is VST2 then the "void*" that is passed to open() is the HWND (you can cast it) of the host window that you are supposed to use as a parent HWND for your editor. If you want to use GDI, then you should probably just ditch the VSTGUI completely and create your own window using your own window class and with the "ptr" as the parent HWND. If you use the SDK class for your plugin, then you can use AEffEditor directly as a base class for the editor.

That said, in general (plugin or not) you should never draw outside WM_PAINT handler. It is technically possible, but there are a number of reasons why it is a BadIdea(tm). The correct way to redraw something is to call RedrawWindow() or InvalidateRect() on the window you created (not the host window!) to queue a WM_PAINT, then in the WM_PAINT handler you call BeginPaint() to get the HDC (which is also automatically setup to clip the region that actually needs repainting) and EndPaint() once you're done.

[kirsty roland]

So I've kind of got it working in a very ugly way.
I can see why people don't like VSTGUI i'll keep at it until I get it working properly.

Thanks
Kirsty

[S0lo]

You could implement/override the default drawRect() in the CViewContainer or CFrame you want to draw in. You can call the default drawRect() inside it to get the default drawing going on, then add your own graphics.

drawRect() it self will give you a CDrawContext object that you can use to get a DC like this:

HDC dc = pContext->getGraphics()->GetHDC();

[kirsty roland]

Yep I'll look into that.
Mystran's idea of ditching VSTGUI and creating my own child window from the host supplied HWND ptr
is tempting and I might also look at opengl for multi-platform support and speed.

Kirsty

[matt42]

Mystran's idea of ditching VSTGUI and creating my own child window from the host supplied HWND ptr is tempting

If only someone detailed the process in the first reply to the thread

[quikquak]

I might also look at opengl for multi-platform support and speed.
Kirsty

Careful with that, as Apple are going to remove OpenGL support one day as it's already redacted.

[kirsty roland]

Mystran's idea of ditching VSTGUI and creating my own child window from the host supplied HWND ptr is tempting

If only someone detailed the process in the first reply to the thread

Sorry mate. My bad
Kirsty

[kirsty roland]

I might also look at opengl for multi-platform support and speed.
Kirsty

Careful with that, as Apple are going to remove OpenGL support one day as it's already redacted.

Typical, there's always one bad apple to spoil the bunch
Kirsty

[hibrasil]

latest VST3 SDK has much better example code (using VSTGUI) than used to be the case.

Alternatively you might like to check the new iPlug2, which has multiple different graphics backend options using IGraphics (iplug graphics engine), or define NO_IGRAPHICS, and do what you like with the window handle provided here https://github.com/iPlug2/iPlug2/blob/m ... gate.h#L93