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

DSP, Plug-in and Host development discussion.
assfortress
KVRer
10 posts since 18 Mar, 2004

Post Sun Oct 30, 2005 11:01 pm

stefankuhn wrote:...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
KVRist
127 posts since 27 Oct, 2005

Post Wed Dec 07, 2005 5:03 am

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
KVRist
69 posts since 15 Feb, 2003

Post Sun Dec 11, 2005 2:33 am

g_worroll wrote: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
regards,
Plughead

guitar-kermit
KVRer
7 posts since 17 Jan, 2006

Post Sun May 21, 2006 4:14 am

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
KVRian
500 posts since 13 Oct, 2004 from Durham, NC USA

Post Wed Jun 14, 2006 8:57 am

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

p2409
KVRer
14 posts since 25 Sep, 2006 from Melbourne

Post Sun Oct 01, 2006 3:59 am

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
KVRAF
2217 posts since 15 Jul, 2003

Post Fri Mar 30, 2007 6:23 am

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
KVRAF
4614 posts since 20 Feb, 2004 from Gothenburg, Sweden

Post Fri Mar 30, 2007 6:26 am

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" :)
Stefan H Singer
Musician, coder and co-founder of We made you look Web agency

cpr
KVRist
139 posts since 8 May, 2007 from California

Post Fri May 11, 2007 12:52 pm

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

User avatar
Chris Walton
KVRAF
2160 posts since 25 Jan, 2007 from the back room, away from his wife's sight (or so he thinks)

Post Fri May 11, 2007 1:18 pm

cpr wrote: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 :D)

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;
}
Full-time Daddy and Software Developer
Part-time Musician and Smartass
Zero-time Intelligent Being
Formerly known as arke, VladimirDimitrievich, bslf, and ctmg. Yep, those bans were deserved.

G&L_player
KVRian
711 posts since 8 Sep, 2005

Post Sun May 20, 2007 2:15 am

I am a programmer. :oops: 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. :lol: 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! :D

laserbeak
KVRian
922 posts since 11 Mar, 2001 from nyc

Post Thu Nov 08, 2007 3:32 pm

useruseruser wrote:
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!! :hihi:

User avatar
Zaphod (giancarlo)
KVRAF
2403 posts since 23 Jun, 2006

Post Tue Mar 25, 2008 11:50 am

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

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

haydxn
KVRAF
3364 posts since 16 Feb, 2004 from atop a katamari

Post Mon Mar 31, 2008 6:46 am

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.
Kick, punch, it's all in the mind.

xoxos
Mr Entertainment
12018 posts since 30 Apr, 2002 from i might peeramid

Post Mon Sep 01, 2008 7:47 am

hardcopy is <$20 on amazon. i found schildt easy to read - precise language, clear and concise enough for me.
you come and go, you come and go. amitabha xoxos.net free vst. neither a follower nor a leader be
tagore "where roads are made i lose my way"
where there is certainty, consideration is absent.

Return to “DSP and Plug-in Development”