What are the most important parts of C++ for coding plug-ins?

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

As I've said a few times, I am learning C++(along with planning a wedding, moving, going back to school, working full time, recording for my church, and trying to do too much other stuff). But since I'm still beginning at it, I was curious. What parts of C++ will come in handy the most when doing VST plug-ins? What parts should I spend the most time with? I am learning all I can, but I want to make sure I don't miss something important. I want to focus on the main things I'll need. Thanks guys! Cheers!

Koolkeys

Post

koolkeys wrote:What parts of C++ will come in handy the most when doing VST plug-ins? What parts should I spend the most time with?
That would be:
* Learning how to avoid making mistakes
* Learning how to diagnose your mistakes quickly
* Learning how to fix your mistakes
* Learning how to write code that alerts you as quickly as possible to recently added mistakes
* Learning how to become irritatingly anal-retentive and precise

You'll know you've gotten the last part down when someone asks you a simple yes/no question and you take five minutes to define terms and check your assumptions against theirs before you feel comfortable giving them an answer.

All the rest is really pretty unimportant.

I'm not f**king kidding.

* Less seriously: start programming 15 years ago.
Last edited by Borogove on Tue Aug 10, 2004 4:02 pm, edited 1 time in total.
Image
Don't do it my way.

Post

koolkeys wrote:As I've said a few times, I am learning C++(along with planning a wedding, moving, going back to school, working full time, recording for my church, and trying to do too much other stuff). But since I'm still beginning at it, I was curious. What parts of C++ will come in handy the most when doing VST plug-ins? What parts should I spend the most time with? I am learning all I can, but I want to make sure I don't miss something important. I want to focus on the main things I'll need. Thanks guys! Cheers!

Koolkeys
Well, apart from the learning to find / avoid mistakes part that Borogove has already mentioned (but is not directly related to C/C++, but more of a general thing IMO), I think there are not many specific features in C++ that make coding Effects / Synths especially easy.

Indeed, I don't use much of the sophisticated C++ features in my synths. I don't use Runtime-Type-Information, for example, because even if you never use dynamic_cast, the language needs to do some book-keeping everytime you create objects, which costs significant performance.

I don't use exceptions, since they are slow and normally not necessary in an Effect or Synth project.

And I try to reduce class inheritance and virtual functions in those parts of the Plugin that are called often / many times per second.

So these are probably the parts that you may NOT need to spend most time with.

In principle you could even go as far as not using C++ at all. I know a number of developers who use C++ only for the VSTSDK - and write all their rendering code in C, obviously for performance reasons.

However, if you're new to writing plug-ins I don't recommend doing it in C. Because in general I think that classes and member functions are more convenient to use and easier to grasp for newbies, than structs and function pointers. (No C vs. C++ war on this statement, please!)

So what you should be good at is to distinguish what entities / aspects of your plug-in are related and belong into one class, and which are unrelated and belong into distinct classes. Finding a good class design, so that the objects can efficiently interact with each other is the real art, IMO.

Apart from knowing C / C++, I think it's even more important to have good knowledge on the VST specification, the sequence of events / calls that the host will do into your plug-in, the way the data flows between your plug-in and your host, etc.

And, as Borogove already mentioned, you should know all the commonly made mistakes that one can make when writing a plug-in. Unfortunately, noone will be able to prevent you from making them. You'll have to make them and learn from them like we all did / do.

That's where the real "know-how" is, not in the C++ or VSTSDK specification. ;)

Hope this helps,
Stefan
http://www.stefan-kuhn.net
Home of Vivaldi MX and Ganymed

Post

* Learning how to become irritatingly anal-retentive and precise
:lol:

---

Its important to remember the 80-20 rule (or some will say 90-10 rule). Generally there is a great deal of code in your program that rarely runs (for example a lot of your GUI stuff). Commonly this figure would be around the 80 or 90 percent mark.

The actual efficiency of this code is not really all that important. You will barely see any performance reduction form using a virtual function as opposed to an ordinary one. (Unless you have defined too many virtuals and have huge vtbl's for your classes, which blow the cache etc).
The areas in your plugin that are critical is the DSP process. You need to make this bit fast, so avoid function calls in your process if possible. If you call a virtual function for every iteration of your process loop, then the performance hit would be significant over the use of an ordinary function.

C++ offers 'inline functions', which will make your life much easer in this respect. C only has macros, which are error prone, don't work well with debuggers, and can also give confounding compiler errors. You do need to take care with inlne functions though (e.g. using static variables in inline functions).

C++ can be used efficiently - its important to learn what the features in C++ cost you, and to know when they are worth the money. To emulate virtual functions, for example, would probably cost you more to do in C than it would in C++, so if you need polymorphism, then use it! C++ was designed to offer a small a performance hit as possible over C. Take a read of "Inside the C++ object model" (Addison Wesley publishers) - this covers many of the 'differences'.

C++ lends itself very well to programming GUI type things, because object oriented programming describes the realtionships and encapsulation of GUI elements well. The performance is not a great issue either - most intensive commands ar calls to libraries such as GDI anyway.

You can program C++ more safely than C++, by using some of the newer operators, such as static_cast and const_cast, rather than the traditional C-style cast. By using these language features, you are more likely to catch errors at compile time than at runtime, which is always a good thing.

Post

When I did my first C++ code, the main errors were all related to bad char and array usages. So here are some tips.

float Number[10]

Means that you have an array of 10 numbers, starting at Number[0] to Number[9], there is no Number[10]. And if you try to load Number[10], it will mostly crash. On Windows-XP sometimes it takes time to crash, but it will and you will be very lost, since the error may not be directly on the time you tried to load Number[10].

Also, when using strings, remember to leave some extra chars at the end as a string END will use extra char information. EG: char Msg[10] you can't do strcpy(Msg,"1234567890"); Is best to use strncpy(Msg,"1234567890",10); This avoid problems. Most times use the strncpy to avoid buffer-overrun.

This is actually the most commom mistake on Windows programs...

Best Regards, WilliamK

Post

Yes. Actually a string defined as:
char s[10];
can only hold a 9-characters strings because of the extra 0 byte. Isn't that lovely... of course, sooner ar later you'll write something longer than 10 chars in there, so you should ALWAYS use a memory checking tool. There are commercial ones around, but I've been perfectly happy with an old (free) one called fortify. This thing traps memory leaks, writes after the end of arrays, ...

Also, if you intend to make some real big plugin, I'd advise to learn a little bit about STL. It has tremedously simplified the UI code in Rhino. Install stlport (www.stlport.org) and enjoy the string, vector, list and hashmap types.

As someone else pointed out, you don't really need the object oriented stuff for the realtime part of your plugin - but unfortunately, 80% (or more) of your code with be graphics, and these will definitely be easier to code (and debug) if you know your way around virtual methods and such.

Maybe try a simple plugin (without GUI) to start with...

'Tick

Post

I love pointers :? For me, this is the most important technology for writing fast, object oriented code in plain C. I use callbacks (function pointers) rather than virtual functions. My most used type is void*. That requires one to know in advance what he does.

Well, even more important than language is the way you organize stuff for reusability, for extensibility and for keeping the overview over everything.

Avoid dependencies between source files. Make sure that changing a header file will only result in compilation of 1-3 .cpp files. In case of inheritance stuff, test and debug the superclasses until they are 100% before implementing tens of subclasses. You need a good concept here. A pencil and some paper is your friend before you start.

When it comes to GUI, there is nothing that really works. VSTGUI isn't bad, but once you're into stuff deeply, you'll also want to support things beyond VST. Hence, try to keep your GUI setup routines as abstract as possible. A cool concept of C++ for this are factory classes. You can derive certain implementations of factory classes for your current environment, and then use the same codebase to create the environment specific objects.

But unfortunately, one has to learn from his own mistakes :P . So, maybe you should make a simple Hello World plugin first, and then analyse what it takes to make it a different plugin or to build it for a different platform. This way you get those ideas like "if I abstract this here, I can put it there for my next project with a single line of code".

Welcome to the club,

;) Urs

Post

WilliamK wrote:Also, when using strings, remember to leave some extra chars at the end as a string END will use extra char information. EG: char Msg[10] you can't do strcpy(Msg,"1234567890"); Is best to use strncpy(Msg,"1234567890",10); This avoid problems. Most times use the strncpy to avoid buffer-overrun.
If you do strncpy that way, you will avoid the immediate buffer overrun, but you now have a non-terminated string which won't print correctly (at best). I recommend that you never call strncpy directly, but instead make a function like:

Code: Select all

char* strncpy_safe( char* dest, char* src, char* length )
{
   char* result = strncpy( dest, src, length );
   dest[length-1] = 0;
   // good catch, stefan
   return result;
}
In its current form, strncpy() is one of the most dangerous functions in the C library simply because it lulls intermediate programmers into a false sense of security.
Last edited by Borogove on Tue Aug 10, 2004 3:59 pm, edited 1 time in total.
Image
Don't do it my way.

Post

texture wrote:C++ offers 'inline functions', which will make your life much easer in this respect.
And in Visual C++, when you say "inline" the compiler will frequently ignore you, so check the assembly output and use "__forceinline" if necessary.
Image
Don't do it my way.

Post

well again, once you get used to STL, you won't ever need strncpy again:

Code: Select all

std::string s = "abcdef";
std::string t = s; // I know, that's a poor example and it should really be std::string t(s) :-) 
unless, of course, you need to work with strings in some time-critical code. This hardly happens when developing vst's, though.

'Tick

Post

Borogove wrote: If you do strncpy that way, you will avoid the immediate buffer overrun, but you now have a non-terminated string which won't print correctly (at best). I recommend that you never call strncpy directly, but instead make a function like:

Code: Select all

char* strncpy_safe( char* dest, char* src, char* length )
{
   char* result = strncpy( dest, src, length );
   dest[length-1] = 0;
}
In its current form, strncpy() is one of the most dangerous functions in the C library simply because it lulls intermediate programmers into a false sense of security.
Yup. So true!

Man, it took me some sweat and tears 'til I finally found out that the ANSI standard defines that strncpy does _NOT_ put a terminating zero character after your string.

Honestly, I recomment using a string class, either STL or self made, that wraps all the ANSI string functions into sensible methods. That's one place where C++ definitely makes sense. Especially, since you would use strings only in parts of the plug-in where performance is no issue (eg. GUI).

Beeing irritatingly anal-retentive and precise too, I took the liberty to correct your code sample, Borogove: :D

Code: Select all

char* strncpy_safe( char* dest, const char* src, unsigned int length )
{
   strncpy( dest, src, length );
   dest[length-1] = 0;
   return dest;
}
Best,
Stefan
Last edited by stefankuhn on Tue Aug 10, 2004 3:58 pm, edited 1 time in total.
http://www.stefan-kuhn.net
Home of Vivaldi MX and Ganymed

Post

Big Tick wrote:well again, once you get used to STL, you won't ever need strncpy again:

unless, of course, you need to work with strings in some time-critical code. This hardly happens when developing vst's, though.
Excellent point. I'm a dinosaur who started using C in 1988, so I may never really be comfortable with the C++ standard library. (I also develop games on consoles for a living, so I'm not comfortable with string implementations which can randomly reallocate memory :)
Image
Don't do it my way.

Post

stefankuhn wrote:[Beeing irritatingly anal-retentive and precise too, I took the liberty to correct your code sample, Borogove: :D
:lol:

*cough* compiler woulda caught that one for me *cough*
Image
Don't do it my way.

Post

Borogove wrote:
texture wrote:C++ offers 'inline functions', which will make your life much easer in this respect.
And in Visual C++, when you say "inline" the compiler will frequently ignore you, so check the assembly output and use "__forceinline" if necessary.
As a sub-note, the functions it typically ignores are those that have complex logic paths and loops in them. Additionally, virtual functions are always ignored (which is obvious if you think about it).

If the inline function is simply returning the value of a member vairable of an object, then the implicit inline function is generally honoured by the compiler (and the inline keyword is not even needed). Impolicit inline functions are those included in the class declaration. You should generally try to avoid mixing your implementation in with the class declaration, but access to private member variavble values or const-references is usually done in this way.
Inline functions aren't limited to member functions of clases though. You can use the inline (or for msvc, the __forceinline) keyword for 'static' functions local to the implementation. The C++ way of doing static local functions is to use unnamed namespaces rather than the 'static' qualifier

e.g.


Code: Select all

namespace {
    inline void myLocalFunction(Foo& bar) {
        ...
    }
}

Post

koolkeys wrote:As I've said a few times, I am learning C++(along with planning a wedding, moving, going back to school, working full time, recording for my church, and trying to do too much other stuff). But since I'm still beginning at it, I was curious. What parts of C++ will come in handy the most when doing VST plug-ins? What parts should I spend the most time with? I am learning all I can, but I want to make sure I don't miss something important. I want to focus on the main things I'll need. Thanks guys! Cheers!
Koolkeys
My tip is very simple: Learn it by doing.
Simply start a plugin project (there are starter examples enougth there) and begin to realize your imagination. Do all problems solve in the order it occurs. (You should have a good book by the hands to immediately find the solutions for your problems.)

I have seen ppl trying to teach themselfes a hole stack of C/C++ books and white papers only by reading...
...they where not really able to code the simplest algorithms and projects in practice finally...

.

Post Reply

Return to “DSP and Plugin Development”