vstgui4.0 creating a DrawContext to draw primitives

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

Hi everyone,

I really need some help! :help:
I've just started writing VSTs and it's a fantastic pain to find information, let alone any deeper tutorials.

vstgui4.0 comes with a tiny and broken tutorial (only a tiny piece of one knob showing), which I've managed to fix after stunning adventures into various other pieces of code elsewhere and intense studies.
Not only that, I have managed to figure out how to create sliders and labels by looking around and experimenting. But everything comes to a squeaking hold as I arrive at dealing with DrawContexts.

Looking at the old "drawtest" of vstgui3.0, it's impossible for me to trace back how any of this works and it seems outdated anyway.

Can anybody tell me or give me a decent hint on how to simply create a drawContext within this code...(and maybe draw a line!? Would be awesome!)

Code: Select all

#include "TutorialEditor.h"

//-----------------------------------------------------------------------------------
AEffGUIEditor* createEditor (AudioEffectX* effect)
{
	return new TutorialEditor (effect);
}

//-----------------------------------------------------------------------------------
TutorialEditor::TutorialEditor (void* ptr)
: AEffGUIEditor (ptr)
{
}

//-----------------------------------------------------------------------------------
bool TutorialEditor::open (void* ptr)
{
	CRect frameSize(0, 0, (VstInt16)512, (VstInt16)256);
	CFrame* newFrame = new CFrame(frameSize, ptr, this);
	newFrame->setBackgroundColor(CColor(60, 90, 110, 255));

       //Is here the right place to create a DrawContext? Is there maybe a totally different thing necessary and what exactly?

	frame = newFrame;
}

void TutorialEditor::close ()
{
	CFrame* oldFrame = frame;
	frame = 0;
	oldFrame->forget ();
}
I would be eternally greatful, really. My goal is to write free synths for the OSC. All I normally need is some strong enough hint to bite my way through the rest. This vst stuff, though, is really rough on a rusty C++ mind- on top of things. :roll:

Anyway, THANK YOU in advance! :pray:
Last edited by Taron on Sun Sep 06, 2015 7:56 pm, edited 1 time in total.

Post

You don't create a CDrawContext. You inherit from CView or CControl, and override the draw() method, which conveniently, is called with a CDrawContext already created for you. You just need to add your CControl to your frame using frame->addView()

Post

Thanks, Big Tick! I'll have to try and see, if I really understand how I practically hook that up. But this helps me to investigate further for sure! THANK YOU! :tu:

If/When I have it figured out, I will still post my finding here for those of us, who also have troubles with that. A tiny piece of source says a 1000 words.

Post

I THINK I GOT IT! :hyper: :phew:

This becomes a custom draw section...

Code: Select all

class TestDraw : public CView
{
public:
	TestDraw (const CRect& size) : CView(size) {}

	void draw(CDrawContext* context)
	{
		context->setFillColor(backgroundColor);
		context->drawRect(size, kDrawFilledAndStroked);
		setDirty(false);
	}

	void setBackgroundColor(const CColor& c) { backgroundColor = c; }

protected:
	CColor backgroundColor;
};

And then you just add it like any other GUI element...

Code: Select all

        ...
        CRect r((20, 100, 120, 150);
	TestDraw * td = new TestDraw (r);
	td->setBackgroundColor(CColor(210, 140, 100, 190));
	newFrame->addView(td);
        ...
YEHAH! Oh man...this drove me bonkers. I have to get used to the whole language again, really, but also to the philosophy of vstsdk and gui.

But you've helped me A GREAT DEAL, BIG TICK! :hug:

Post

I've managed to get on top of these drawing matters, including gradients and paths. Yay! :hyper:

However, it's extremely rough to move forward an inch from there, though, because vstgui 4.0 has next to no examples from what I found and is vastly different from earlier version.

I'm currently trying to make Curve Handles, but it still kind of escapes me how to achieve that. I feel seriously dumb, yet, I simply am a noob, I'm afraid.

The vstgui.h no longer has such things as waitDrag() or the likes from what I find, thus the only example of something remotely similar in vstgui 3.0's "drawtest" no longer applies.

Apparently even a vague hint gets me to leap pretty far, thus I'll be super grateful for yet another. Trust me, though, I'm seriously ashamed to ask. If only I could find more examples...something that covers more than a freaking CKnob, haha. I could already create a far more useful tutorial, haha.. damned.

Maybe just a hint on where I might find more useful examples? Just realize that you'll make the world yet a bit bigger... :)

Post

Nevermind, it took me a moment, but I think I figured out a way to do it!

If somebody was interested, I could turn this into a little bit of a dev log, actually. I know, I would've loved to run into such a thread, but anyway.

It's amazing how gradually things begin to make sense to me. The smallest mistakes are unforgivable and when one doesn't quite know anything, it's extremely hard to figure out what exactly was wrong. But piece by piece I get into the groove of this, including C++ again.

The new methods in vstgui 4.0 seem a lot cleaner to me as I compare it to 3.0 and even 3.6. In 3.6 seem to be a number of deprecated safety nets, which are gone in 4.0. That's most likely part of the pain there. Fortunately I haven't yet dealt with any cross platform matters, but for the time being I'm just happy there's no trouble in compiling 64 bit on windows.

Some of you may already think: "Dear god, please, don't let this guy try cross platform!" :pray: "...the pesky questions!" :roll:

Anyway, just to let you know: I've got things under control for now, and my first vst will be a perfect catastrophe, but it WILL BE! :hyper:

Post

Ok, I found an idiotic problem for which I can't yet find a solution:

pseudo:
onMouseDown activates a move
onMouseMoved moves when move is active
onMouseUp should deactivate the move

Now I've read that onMouseMoved seems to flush the mouse button state from what I understand, as do all of those calls.
Is there an alternative to that, or what might I misunderstand?

As always, thanks in advance for any help!

Post

You can get the current state of the buttons by calling CFrame::getCurrentMouseButtons()
Or you can save the buttons state that caused you to start a drag in onMouseDown();

Post

Hmmm, that means that today will be dedicated to wrapping my head around more of where and how I have to hook into the common vst procedures via vstgui... I don't know enough, yet, that's for sure.

I made a handle class yesterday only as CView. The Buttonstate that comes with its Mouse calls seems to be useless, why ever? Although I have a hard time imagining this to be right, I guess, I have to try making a global parameter (or at least accessible by all gui classes, which I would update from my CFrame. Yet, I'd have to find under what call I can get mouse states... I do remember having seen ::mouse at some point, so...god I feel like a moron, haha.

Very tricky that stuff. :|

THANKS, again, though! You very much rock, BT! :tu:

Post

Sometimes whining helps me, so I will whine a little while I desperately try to revise my approach, literally shooting into total darkness (or my blindness, whatever it is).

I think, I'm doing it all wrong, trying to use a CView class to make an area with curve handles, one might move around.
I don't know how... danged... in my main gui class ( TutorialEditor : public AEffGUIEditor, public CControlListener )...I can't see how I can get mouse events, because I don't know how to get a constant listener for mouse events in there. I still don't know how it even evaluates other than being called once to set up entry points for the procedures somehow (magically). It's so painful and frustrating not to find any useful documentation or even a single reasonable example on any of this other than the figurative "Hello World", really, haha. It's stunning how far I've already come without knowing nothing, but jeeeez.... ...I mentioned "whining", right!? :roll:
I know, there will come a split second in which it all becomes clear to me, but I can't tell when that may happen just yet. :bang:

I shall make a vow now: If I ever figure out how all this works and I manage to compile a full functional, beautifully running vst, I will make a simple and powerful tutorial to finally give aspiring developers a chance to produce something decent!

Post

You shouldn't make a CView for the handle. You should have a CView for the entire area where you are going to draw your curve and handles. Then in draw() you draw your curve and handles. In order to detect if you are clicking on a handle you will have to test the 'where' parameter in onMouseDown.

Post

Oh, that's what I have, sorry for being ambiguous there.
CView is the "area" in which the handles are. Then at onMouseDown and Up and Moved I check for where isinside.

The CView is then added to the frame of my AEffGUIEditor, just like CKnob and slider and such.

However, the problem remains that onMouseUP never gets called (checked with breakpoint in debug, too).
I was wondering, if CView really would be the right choice for the class to begin with?
I thought about trying CControl or CViewContainer or such, but can't handle those, yet. Without knowing what I'm doing, it's tough to track down how to properly declare everything so that it's not an abstract class or the likes, you know. In fact, you might know, but I certainly don't. :shrug: ...very much unfortunately.

I did a temporary thing where MouseDown toggles the move activation. It's really dumb, though. Dragging would be the only truly appropriate solution. Needless to mention that I can't shake the feeling that I'm doing something fundamentally wrong. Like I have a flawed approach. :scared:

Maybe I should just prepare the code to show you, unless that becomes a little to imposing?

Post

Ok, I put it all into the CView class, which works just the same...

Code: Select all


const CColor kMainColor = { 154, 118, 81, 255 };
const CColor kHighlightColor = { uint8_t(154 * 1.2), uint8_t(118 * 1.2), uint8_t(81 * 1.2), 255 };
const CColor kOffColor = { uint8_t(154 * 0.5), uint8_t(118 * 0.5), uint8_t(81 * 0.5), 255 };


class MyHandle : public CView
{
public:
	MyHandle(const CRect& size) : CView(size) 
	{ 
		active = false; 
	}
	
	CMouseEventResult onMouseDown(CPoint &where, const CButtonState& buttons)
	{
		if (where.isInside(hsize))
		{
			active = !active;
			invalid();
		}
		return CView::onMouseDown(where, buttons);
	};
	CMouseEventResult onMouseUp(CPoint &where, const CButtonState& buttons)
	{

		active = false;
		invalid();

		return CView::onMouseUp(where, buttons);
	};	
	CMouseEventResult onMouseMoved(CPoint &where, const CButtonState& buttons)
	{
		if (active == true)
		{
			CPoint os = hsize.getTopLeft();
			pos.offset(where.x - os.x - 5, where.y - os.y - 5);
		}
		if (where.isInside(hsize))
			setColor(kHighlightColor);
		else
			setColor(kMainColor);

		invalid();
		return CView::onMouseMoved(where, buttons);
	};
	void setColor(const CColor& col){ color = col; }
	void setPos(const CPoint& p){ pos = p; }
	void draw(CDrawContext* context)
	{
		context->setFrameColor(CColor(154, 118, 81, 128));
		context->drawRect(size, kDrawStroked);
		context->setFillColor(color);
		hsize(0, 0, 10, 10);
		hsize.offset(pos.x, pos.y);
		context->drawRect(hsize, kDrawFilled);
	}
protected:
	CRect hsize;
	CPoint pos;
	CColor color;
	bool active;
};
Naturally, this is just a tiny (sloppy sandbox) test with just one handle, but it shows the principle I thought of.
This is, of course, just the sad alternative with the onMouseDown activation toggle for moving the handle.

Post

in onMouseDown you should return kMouseEventHandled instead of CView::onMouseDown(where, buttons)
same for onMouseUp and onMouseMoved.

Post

AH, you're KIDDING me! :o
I've tried it before, while things were mildly different (in a million and one ways, of course) and now you're perfectly right on!?! :shock:

Dang! :lol:

:roll: :tu:
Yep, that does it! :hug:

Post Reply

Return to “DSP and Plugin Development”