|
|||
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. |
|||
| ^ | Joined: 18 Mar 2004 Member: #17454 | ||
|
|||
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. |
|||
| ^ | Joined: 26 Oct 2005 Member: #85722 | ||
|
|||
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 |
|||
| ^ | Joined: 14 Feb 2003 Member: #5940 | ||
|
|||
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" |
|||
| ^ | Joined: 17 Jan 2006 Member: #94783 | ||
|
|||
-- message deleted -- too far off topic for a sticky. |
|||
| ^ | Joined: 13 Oct 2004 Member: #44373 Location: Durham, NC USA | ||
|
|||
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. |
|||
| ^ | Joined: 25 Sep 2006 Member: #121426 Location: Melbourne | ||
|
|||
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 |
|||
| ^ | Joined: 15 Jul 2003 Member: #8071 | ||
|
|||
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" |
|||
| ^ | Joined: 20 Feb 2004 Member: #12924 Location: Gothenburg, Sweden | ||
|
|||
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... |
|||
| ^ | Joined: 08 May 2007 Member: #150251 Location: California | ||
|
|||
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 Good: 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: // 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 |
|||
| ^ | Joined: 25 Jan 2007 Member: #137320 Location: in ur basement, codin ur programz | ||
|
|||
I am a programmer. 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. 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! |
|||
| ^ | Joined: 08 Sep 2005 Member: #80600 | ||
|
|||
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!! |
|||
| ^ | Joined: 10 Mar 2001 Member: #334 Location: nyc | ||
|
|||
books, dsp, c++ learning... all important staff, but_
Start a project you believe in. You'll have plenty of energy for learning details |
|||
| ^ | Joined: 23 Jun 2006 Member: #111268 | ||
|
|||
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. ![]() |
|||
| ^ | Joined: 16 Feb 2004 Member: #12528 Location: atop a katamari | ||
|
|||
hardcopy is <$20 on amazon. i found schildt easy to read - precise language, clear and concise enough for me. |
|||
| ^ | Joined: 29 Apr 2002 Member: #2639 Location: i might peeramid |
| KVR Forum Index » DSP and Plug-in Development | All times are GMT - 8 Hours |
|
Printable version |
Disclaimer: All communications made available as part of this forum and any opinions, advice, statements, views or other information expressed in this forum are solely provided by, and the responsibility of, the person posting such communication and not of kvraudio.com (unless kvraudio.com is specifically identified as the author of the communication).
Powered by phpBB © phpBB Group







