COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :
Old 08-27-2009, 02:05 PM   #1
deraudrl
Human being with feelings
 
Join Date: Aug 2009
Posts: 5
Default IPlug/IGraphics Questions

I've got my IPlug and lice libraries compiled and linked ok, complete with the various enhancements and corrections noted elsewhere in this forum, and the example plug-in compiles, links, loads, and works fine. I wanted to see how the multi-font text extensions worked, so tried adding some static labels to the controls on the example.

Adding an ITextControl worked fine:

pGraphics->AttachControl(new ITextControl(this, rect, text2, "Gain (Right)"));

What didn't work (error when loading using SAVIhost) was simply drawing to the background using DrawIText directly:

pGraphics->DrawIText(text2,"Gain (Right)",rect);

which is very odd, since all the Draw method for ITextCOntrol does is retrieve the char* string from a private member and make essentially the same call to DrawIText.

I get similar results using other drawing primitives in the IGraphics class (e.g. DrawLine or FillIRect: either the DLL simply fails to load or the call does nothing, or at least nothing visible. Is it something tricky that the IControl class is doing? (The IKnobLineControl works, calling DrawLine.)

I can't tell exactly where it's dying (still getting up the learning curve with debugging DLLs), but is there something obvious I'm missing?

Last edited by deraudrl; 08-27-2009 at 02:12 PM.
deraudrl is offline   Reply With Quote
Old 08-27-2009, 04:43 PM   #2
deraudrl
Human being with feelings
 
Join Date: Aug 2009
Posts: 5
Default

Some progress: got the debugger to quit complaining about my compiler settings...

As it turns out, the base drawing context isn't even created until the AttachGraphics() call. Moving that up right after the MakeGraphics call handled the cases where the DLL was failing on load.

The real issue is the background: it's a control and gets redrawn...a lot. So it covers over everything that isn't a control (they redraw in back-to-front order), rendering all of the supplied drawing primitives totally useless outside of the Draw method for a IControl object. This means that even simple things like a black 'slot' for a fader background either has to be part of the background bitmap or drawn by the fader control itself, which the default fader class doesn't do.
deraudrl is offline   Reply With Quote
Old 08-28-2009, 09:42 AM   #3
cc_
Human being with feelings
 
Join Date: Mar 2009
Posts: 256
Default

Quote:
Originally Posted by deraudrl View Post
This means that even simple things like a black 'slot' for a fader background either has to be part of the background bitmap or drawn by the fader control itself, which the default fader class doesn't do.
For this case you could create a new subclass of IFaderControl and override the Draw method to draw your 'slot' bitmap before calling IFaderControl's Draw.
cc_ is offline   Reply With Quote
Old 08-28-2009, 12:44 PM   #4
deraudrl
Human being with feelings
 
Join Date: Aug 2009
Posts: 5
Default

Quote:
Originally Posted by cc_ View Post
For this case you could create a new subclass of IFaderControl and override the Draw method to draw your 'slot' bitmap before calling IFaderControl's Draw.
Understood.

I guess what's bugging me is that the IPlug library is (or seems to be) talked about here like it's a new-and-better replacement for the Steinberg stuff, but it seems like, at least at this point, it only replaces a subset of it. As with this example, to get rather fundamental functionality already present in VSTGUI, I have to roll my own.

Bit of a disappointment, that. I'm willing to be convinced otherwise though.
But in the words of Clara Peller, "Where's the beef?"

Last edited by deraudrl; 08-28-2009 at 12:49 PM.
deraudrl is offline   Reply With Quote
Old 08-29-2009, 01:10 AM   #5
bvesco
Human being with feelings
 
bvesco's Avatar
 
Join Date: Jun 2007
Posts: 125
Default

For me, the advantage of IPlug is not the GUI. Don't get me wrong, the GUI layer is sufficient for my needs, but it is not perfect. I also much prefer VSTGUI. The "beef" is in the cross platform, cross standard (VST and AU) aspect of IPlug. You aren't going to get cross platform plugins in VST and AU formats with the "code once" luxury of IPlug if you are using straight VST and AU SDKs. I have actually toyed with the idea of grafting VSTGUI on top of IPlug for quite some time. It's just too much work for me right now when I'd rather be writing plugins
__________________
Audio tutorials and articles: http://www.benvesco.com/tonemonster/
My VST plugins: http://www.vescofx.com/
bvesco is offline   Reply With Quote
Old 08-29-2009, 01:11 AM   #6
cc_
Human being with feelings
 
Join Date: Mar 2009
Posts: 256
Default

If you only want to do VSTs then maybe VSTGUI is a better solution. The advantage of IPlug is that it lets you generate Audio Units as well. Edit: bvesco beat me to it!

I have been rolling my own controls as I needed them. So far just a switch with in between states (I posted that here), and a spinner control (a text display that you can change by dragging up and down).
cc_ is offline   Reply With Quote
Old 08-29-2009, 07:05 AM   #7
deraudrl
Human being with feelings
 
Join Date: Aug 2009
Posts: 5
Default

Quote:
Originally Posted by bvesco View Post
For me, the advantage of IPlug is not the GUI. Don't get me wrong, the GUI layer is sufficient for my needs, but it is not perfect. I also much prefer VSTGUI. The "beef" is in the cross platform, cross standard (VST and AU) aspect of IPlug. You aren't going to get cross platform plugins in VST and AU formats with the "code once" luxury of IPlug if you are using straight VST and AU SDKs. I have actually toyed with the idea of grafting VSTGUI on top of IPlug for quite some time. It's just too much work for me right now when I'd rather be writing plugins
Ok, that matches up with the direction my thinking was going.

I appreciate the concept of 'cross-platform' as much as the next guy, but I don't own a Mac (the last time I touched an Apple product was when I sold my Apple II+ in 1985) and I'm waaaaay over my lifetime quota of Unix/Solaris/Linux programming. And this is just a hobby for me.

I guess my survey of class libraries and graphics frameworks still has some distance to cover. But at least now I seem to be checking them off the candidate list faster than I'm adding new ones.

Thanks.
deraudrl is offline   Reply With Quote
Old 08-29-2009, 07:14 AM   #8
deraudrl
Human being with feelings
 
Join Date: Aug 2009
Posts: 5
Default

Quote:
Originally Posted by cc_ View Post
I have been rolling my own controls as I needed them. So far just a switch with in between states (I posted that here), and a spinner control (a text display that you can change by dragging up and down).
I had already added your 'switch' to my configuration. Took me a minute to figure out what was supposed to happen visually, but I like it.

(Nice subclassing example BTW. I'm still slogging up the C++ learning curve...I think the 25 years of C coding is actually slowing me down.)
deraudrl is offline   Reply With Quote
Old 08-31-2009, 10:34 AM   #9
bvesco
Human being with feelings
 
bvesco's Avatar
 
Join Date: Jun 2007
Posts: 125
Default

Oh, there's the additional advantage of programmatic simplicity even if you're "only" doing VST on Windows. When you want to stand up a new plugin with the Steinberg SDK it requires you to fill in a few dozen helper methods. If you want a gui then you have to fill in another dozen or so methods and all this happens across two header and two source files. Then you've got to worry about interactions of a whole bunch of things like settings parameters from the gui, setting parameters in the gui from the host, etc. With IPlug you set up a configuration file, and do most of your work in a single header and source file.

Take parameters for instance. With the VST SDK when you add a new param you have to fill in methods to get the text display of the param, the numeric display of the param, set the param by float, set the param by text, a converter method to go from text to float, and then set up communication between the param and the gui with setters in both directions that can detect when is the appropriate time to set and when to ignore (for instance, don't set the value back on the gui control if the gui control was what set the param to begin with). For IPlug you declare a new param object, and if you need extra work you give it a pointer to a function that will do that extra work. Done. The IPlug framework handles all the extra stuff itself.

I/O is another example. A plugin with multiple in/out configurations in the stock VST SDK has to call the constructor with a beginning config and then implement get/set speaker arrangement functions which are poorly documented and not entirely clear. Once you decipher those you are likely going to be writing switch statements and other possibly complex logic to figure out when it is ok to set which pin configuration. With IPlug you go into your config file and enumerate the pin configs you want. Example: "1-1 1-2 2-2" would give your plugin mono to mono, mono to stereo, and stereo to stereo pin configurations with no additional work by you.

Params and I/O aren't the only thing that have that kind of refinement, but they illustrate how nicely IPlug is put together.

Also, re: my earlier comments

I actually like IPlug's gui quite well, but VST GUI handles fonts more capably and is better with regards to handling manual input with regards to the user interaction portion of the exchange. The nicer font handling and the improved interaction handling are enough to make me yearn to go back to the heavy handed implementation of VST GUI (but I'd still like it on top of IPlug). Either that or improve IPlug's own performance in these areas.
__________________
Audio tutorials and articles: http://www.benvesco.com/tonemonster/
My VST plugins: http://www.vescofx.com/
bvesco is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 10:26 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.