More noob questions

[Rock Hardbuns]

Hey..

Im thinking of getting into making VSTi:s and Im trying to get a realistic idea of how large a commitment is required before I can bring my designs into reality.

I do Java and PHP coding for a living and I have dabbled with game coding in C.

1. After studying various materials, mainly CMs tutorial, making effects strikes me as suprisningly straight forward. I assume though that VSTi:S are more complex but how much more?
If a simple delay effct is 100 LOC. How many are a basic monosynth (osc-filter-amp with two envelopes.)
I understand that any answer is a rough aproximation.


2. I keep reading C++ is the most widely use language, but as I look at code examples all I see is plain procedural code. (It looks much like game code actually where input is passed through a series of engines and results in the rendering of a frame.)
So I guess the question is, why not plain C.
Is there some particular feature of C++ I should read up on?

3. Is it as much fun as it seems?

[Shifrin]

Hi,

I'm getting into this myself, actually started a long time ago then left what I'd done - was too busy with other things.

Most of the DSP code I've found and read is written in straight C, however the VST SDK is C++. I'm only toying with effects at the moment, but hope to write some midi effect plugs and then, maybe, an instrument.

Writing the code/using the SDK (and doing graphics for GUIs ) isn't that hard for someone who already programs but learning DSP <i>is</i> - at least I'm finding it tough going. Hence my choice of starting with an effect. It seems to me that one of the hard things in making an instrument is the oscilators - writing good/clever code that minimises aliasing.

It IS great fun though! Not sure if this post is of any help but I thought I'd reply as I'm only starting out too and any pointers anyone else could give would be great!

Shif.

[Rock Hardbuns]

I hear you on the DSP thing. Ive been reading that online DSP book. Its tough to assimilate it all, but Im guessing it will sink in when I begin to apply it.

BTW: I had the idea that one might build a "convolution synth". Convolution effects are pretty common, but how about generating waveforms this way and useing samples for Impulses. Possible, or am I getting it all wrong?

[Phaedo]

Well, convolution involves taking the imprint of a dirac pulse and convolving it with an audio stream, so classicaly, it doesn't make sense. That doesn't mean there aren't interesting synth things you could do with convolution, though.

[Rock Hardbuns]

Yeah, I was thinking about using a pure sine or something as a "carrier" and then apply impulses to it.

But come to think of it.. that would just result in an akward wavetable type of synth.

[Urs]

I assume though that VSTi:S are more complex but how much more?

Hmmm...

just for "estimation of dimension", hehe, and how things develop...

Zoyd (based on my first VSTi from 1999/2000): ca. 5000 lines, spread across 4 files dsp, 10 files gui (could be done with VSTGUI, tho)

Zebra: Many more lines, spread across 50+ files dsp, 30+ files gui... (plus headers)

You see, as these are subsequent projects, one of the most important things is keeping stuff extensible.

So I guess the question is, why not plain C.

Well, hehe, look above, to make stuff extensible, you have to build it in modules. Modules perfectly fit the object oriented approach of classes in C++.

This is good for control and for setting things up. Management in my stuff is build upon C++.

But then, when it comes to processing, it's speed that counts. Within that, I just use plain C. And a lot of nice little hacks, to minimize memory consumption, avoid conditional branches etc.

Cheers,

Urs

[pljones]

But then, when it comes to processing, it's speed that counts. Within that, I just use plain C. And a lot of nice little hacks, to minimize memory consumption, avoid conditional branches etc.

Does anyone have any info on how GCC and G++ compare (to each other) when it comes to speed of code generated? (I compile all my procedural code with G++ anyway, so I'm assuming they're not much different..!)

<OT rant>
A good, structured approach to program development can be undertaken in most languages. (Trust me, I'm refactoring COBOL to keep myself amused at work at the moment...) The benefits of well-architected OO code over well-architected non-OO code are not huge in the longer term. In the short term, it's certainly easier to impose good architecture in OO because it lends itself well to the structured programming paradigms and is less forgiving of a poor approach.
</OT rant>

[Rock Hardbuns]

Good info. Thanks.
Im gonna give this a shot.

[Phaedo]

I've got to admit, my impression was that g++ and gcc were the same compiler to most intents and purposes. pljones and urs are both right though:
Well-structured code is easier to maintain than unstructured code, no matter what the language.
Clever code is faster than stupid code, no matter what the language.

My personal recommendation: worry about developing well-structured code with no bugs first, then worry about the CPU hit. And profile stuff before you recode, FFS. Mate of mine does computer games for a living and he says the bane of his life is over-optimised unimportant code.

[texture]

Yeah, I was thinking about using a pure sine or something as a "carrier" and then apply impulses to it.

But come to think of it.. that would just result in an akward wavetable type of synth.

If you apply an impulse to a sine wave, you'll only adjust its phase and magnitude. You might also add a bit of a tail, or a pre-delay. Convolution is essentially a very big per-sample multitap delay, with each point in the impulse describing the magnitude and delay time of each 'one-shot' tap.