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

[assfortress]

...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....

Where can i find some literature on this? thanks.

edit- so i feel like a complete ass, i had this thread open in another window. however there is alot of information there. id still be intrested if anyone has any info specifically on the interaction between the plug-in and the host.

[g_worroll]

As for the Steinberg SDK... you may have to change the .def files so that it compiles. It tries to put a main function where it doesnt' belong. That might work on compilers other than the one thats part of VC++.NET Express, but it does *not* work there until you change it. Took me a fair amount of research to figure that out. If you have trouble working it out, I can send you the corrected files...

There were also some minor issues I can't recall the specifics off offhand in the actual source. Not sure if it would compile without changing, but it was fairly bad code IIRC. Bad enough I wasn't confident it would run as expected even if it would compile.

[plughead]

As for the Steinberg SDK... you may have to change the .def files so that it compiles. It tries to put a main function where it doesnt' belong. That might work on compilers other than the one thats part of VC++.NET Express, but it does *not* work there until you change it. Took me a fair amount of research to figure that out. If you have trouble working it out, I can send you the corrected files...

Hi,
I'm getting compiler error that sounds like this problem. Is there a way I can get an example VST program that compiles ok on the VC++.NET platform?
Many Thanks

[guitar-kermit]

Highly recommended books:

"Effective C++ : 55 Specific Ways to Improve Your Programs and Designs"
"More Effective C++: 35 New Ways to Improve Your Programs and Designs"

[learjeff]

-- message deleted -- too far off topic for a sticky.

[p2409]

If you've got a non-C programming/technical background, the whole pointer thing really. And I don't mean 'oh yeah a pointer is like a mailbox etc.' that you read in a book, I mean a really familiar, deep understanding of pointers/addresses and the way compilers handle these things is critical. THe rest of the advice above is really good too, especially the inline and strncpy bits. With the latter, a good pointer/address knowledge will reinforce your understanding of this bugger of a function.

[wrench45us]

one of my favorite developer buddies had the three prong approach
make it work
make it right
make it fast

that makes sense a lot of times because starting out you want to to see if some simple concepts will even work esp on the large architectural level -- check that interfaces work
then you immediately refactor with what you've learned
and that's also really good to see that your design is following some guidelines that makes it easy to refactor 'cause that's just ongoing and the better designed it is, the easier that is to do
and somewhere in there things start to get optimized for speed and people have already provided some really good tips for that

[stefancrs]

I find that when dealing with high performance stuff, you really can't simplify the process to those three steps. Due to step three. You often end up redoing the "make it right" part, just to increase efficiency. The code might be way uglier and less reusable, but if it HAS to be effective, there's really not much to do about that.

Of course, it's always about making compromises, so it's not like "to make it fast it has to be dead ugly" or anything. But uglier than when "right"

[cpr]

comment your code well... I know this has nothing to do with the actual code, but once you've been away from the code for a while, especially if has become 'ugly' from optimization, having that documentation embedded in the code will make your life so much easier.. no more 'why the hell did I do that?' moments..

and the books that guitar-kermit recommends will set a great foundation for keeping you out of many of common problems...

[Chris Walton]

comment your code well... I know this has nothing to do with the actual code, but once you've been away from the code for a while, especially if has become 'ugly' from optimization, having that documentation embedded in the code will make your life so much easier.. no more 'why the hell did I do that?' moments..

I'd like to add that there's good commenting and theres bad commenting. And I'd rather have no commenting than bad commenting.

Personally, I comment sparsely, and try to make code that explains itself. Of course, I make sure that I document hacks well (things like manual circular buffers because they always look weird in code when theres a bunch of pointers going around )

Good:

Code: Select all

float note2freq(float midiNote)
{
    // TODO: figure out frequency for midi note 0 for 
    // optimigazation (my IDE highlights "TODO") 
    // A4 = 440Hz = Midi note 57
    return 440 * powf(2, (midiNote - 57.0f) / 12.0f);
}

Bad:

Code: Select all

// converts a midi note to frequency
// takes: n = midi note to convert
// returns: frequency
float n2f(float n)
{
  // use A4 as a base point, first because everybody
  // knows A4 is 440Hz but also because I'm a lazy
  // c**t who doesn't feel like doing the tiny little
  // math needed to do a tiny little optimigazation.
  // then again, im not doing it per sample .. or am
  // I!? I dunno. I should probably fix this someday. 
  float f;
  // f is now the midi note offset between the
  // note and A4 ... simply by subtracting
  f = n - 57;
  // there are 12 midinotes in an octave
  // so now, f is an octave offset by dividing it by twelce
  f /= 12;
  // to go up an octave, you double teh frequency
  // i didnt know how to scale that so i went on musicdsp
  // and found a code snippet in delphi that did that. man,
  // delphi is such an ugly language! c++ is so much prettier
  // especially when you comment alot and start to verbosely 
  // rant inside the source code for no apparent reason
  f = powf(2, f);
  // the base frequency of A4 is 440Hz ... duh, everybody knows
  // THAT :)
  // multiply f by 440
  f *= 440;
  // return f
  return f;
}

[G&L_player]

I am a programmer. I probably have a ismilar background to quite a few guys in this thread- C/C++, Perl (and Perl OO), SQL, most of the big databases...worked on many big systems (e.g. the one you slide you Visa card through; C++, BTW).

I tried my hand at DSP development quite a few years ago, but realised that I didn't have the math background to be a creative as I'd like to be. In addition, I didn't want to be coding all the time, simply put. Sometimes, I wish I stuck with it; most of the time, I don't. Synthedit is still appealing to me, as I'd love to use that for a wrapper for some sample-based ideas that I've been carrying around.

IMHO, I'd get a compiler that contains a good debugger. Learn how to work with the debugger, so you can work backwards. In other words, when something gets flagged, understand what it means in your program, and make the fix. Initially, you'll prolly have a lot of memory-type errors, if working with C/C++. The MS and Delphi compilers are highly recommended. The educational discount for these products is unbelievable! Both are around $100, so check it out. These compilers will take you right to the spot in your code- much better than just getting a message and having to know what it means. Also, these products are very good for creating little test programs that you can use to check your understanding- a huge leg up when learning!

I'd recommend getting a test program that's always able to form a clean build, firstly! This way, you can add all new libs to this first, before adding them to your project. Getting a clean build is a often a daunting task for new-bees and veterans alike, until they get used to working with the components. After awhile, you'll know what to expect. For example, when the new VST SDK comes up (e.g. v2.4), add it to your template program first; get it to build and run; then add it to your project. Getting a good build and understanding compiler options is essential. It's a go/no-go proposition, simply put.

You'll learn to code by looking at a lot of source code- period. All the books and manuals in the world won't make your project go. The source code will. There are a lot of libraries that can save you tons of work. You'll kick yourself later, if you discover them later. FYI: you can use these to create test modules and some of those little programs that I mentioned. Get as many DSP source programs as you can and get it to build firstly! Then start making mods. Once you have a template program that you can modify and refer to for builds and mods, you're on your way. The rest is learning what everything does and how/why.

The O'Reilly books on C/C++ are very useful, and they make the source code available online. FYI: "C++ The Core Language," is essentially for C programmers who are learning classes.

Best of luck!

[laserbeak]

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...

.

that would be I!!

[Zaphod (giancarlo)]

books, dsp, c++ learning... all important staff, but_

Start a project you believe in.
You'll have plenty of energy for learning details

[haydxn]

Just saw on the VC++ start page that Herb Schildt's C++ Beginner's Guide is now available to read from Microsoft.

C++ Beginner's Guide

You can download the chapters as PDFs or some other format (XPS).
Might come in handy for newcomers.

[xoxos]

hardcopy is <$20 on amazon. i found schildt easy to read - precise language, clear and concise enough for me.