A Collection of Useful C++ Classes for Signal Processing

[Music Engineer]

Ironically the whole point of C++ is that it allows you to keep on writing a = b + c for types the compiler implementer never dreamed of.

yeah - like so:

Code: Select all

// library code:

template<class T>
class Complex
{

public:

  T re, im;

  // ...define operators

};

template<class T>
class Matrix
{

public:

  T **data;
  int numRows, numColumns;

  // ...define operators

};



// client code:

Matrix< Complex<double> > a, b, c; // matrices with double-precision 
                                   // complex elements


// assign b, c

a = b + c;

...you would write code for complex arithmetic once, for matrix arithmetic once and reap the functionality for integer-complex, float-complex, double-complex, long-double-complex, integer-matrices, float-matrices, ...etc, all kinds of complex-matrices and so on. in C, you would perhaps write a struct FloatMatrix and then write functions like multiplyFloatMatrices(FloatMatrix *a, FloatMatrix *b, FloatMatrix *result). when you want to do the same thing later with a DoubleMatrix, you would write the same stuff again with only different datatypes in the function declaration. code duplication at its worst. but for certain stuff, plain old C is certainly appropriate.

..or is there a way to do this C that i may have overlooked?


OK - this was a little off-topic. my conclusion: C++ can sometimes be ugly, but is also very powerful. but C can be just as ugly, as well.

[kuniklo]

Hows the Visual Studio integration with those?

I haven't actually tried this but there appears to be a plugin for Mercurial (aka HG):
http://visualhg.codeplex.com/

And something similar for git:
http://sourceforge.net/projects/gitextensions/

Mercurial has a better reputation for working well on Windows but I prefer the more flexible branching model of Git, so I use Git, primarily from the command line.

[Elhardt]

SVN is a version control system, bastard son of CVS, on non-speaking terms with mercurial, git, and various others.

There are many SVN programs available, and will be one for your platform. TortoiseSVN is highly regarded on win, as its explorer integration is very useful. SmartSVN is java based and available for a number of platforms. I quite like SmartSVN.

The sourceforge page for DSPFilters will have the URI for an SVN program to use, then you specify a local directory, and you can download a copy of the repository which may well have fixes that supersede the official releases.

That help?

btw, do I recall from years previously that you are indeed that Elhardt of the Sage fame? If so, I applaud your ingenuity - that was a masterpiece [I'm serious, I thought it marvellous ]

I searched youtube for SVN and found a video suggesting TortoiseSVN and showing how to use it. Looks like somewhat of a pain in the ass, and this whole SVN thing has just added a bunch more time sucking stuff to deal with. It may end up being faster and more straight forward for me to sift through the posts I found in the SVN trunk, and copy and paste the changes manually, especially if I only need a few of them to get the coefficients dump working. Wish the zip file would just be updated with the latest.

And yes, I'm the Elhardt of the Bahn Sage, and later the Seekers SMS-2000. I'm glad you (and others) enjoyed it. I got a lot of fan mail after admitting to doing it.

-Elhardt

[thevinn]

I put up a new .zip archive so you don't have to do that. It's version 0.9.6b and it reflects the latest sources:

http://code.google.com/p/dspfilterscpp/downloads/list

The file is "DspFilters_FullSource_0.9.6b.zip"

[Elhardt]

OK - this was a little off-topic. my conclusion: C++ can sometimes be ugly, but is also very powerful. but C can be just as ugly, as well.

There's part of the reason why C++ is hard to follow, it's because you're trying to cover all possibilities, and C++ seems to be trying to do too much pre-compiler stuff. If I need to write a matrix multiply, I know what data type I need to use. I don't need, nor have any use for one that covers every known data type to mankind, which is what leads to large bloated code sizes. Also, for some reason this C++ topic keeps centering on templates, as opposed to all of the other annoying things I've listed. Maybe a template allows you to not have to duplicate source code, but that doesn't affect the final code size. It just means now that your source code doesn't represent the object code which makes it harder to follow. Probably similar to a macro assembler where when you use macros it's no longer clear what actual code is being generated.

None-the-less, yes C can also look ugly, but most of what it does is straight forward and easy to understand. It's not much different than any other computer language. Since I do most of my time critical stuff in assembly, I need to know where the data is and what data types are being used, something that C++ programmers seem to go out of their way to obscure. I just get the impression that too many programmers today don't understand that there are too many lines of code and additional crap that shouldn't need to be there. I just ran across "Go", and new computer language by Google. They flat out lie when they say "Go is expressive, concise, clean, and efficient". Were they born yesterday. A simple "Hello World" program shows the difference between Go and BASIC:

***** Go *****
package main
import "fmt"
func main() {
fmt.Printf("Hello world!")
}

***** BASIC *****
print "Hello world!"


Today's programmers seem to geek out on convoluted complexity.

[Elhardt]

I put up a new .zip archive so you don't have to do that. It's version 0.9.6b and it reflects the latest sources:

http://code.google.com/p/dspfilterscpp/downloads/list

The file is "DspFilters_FullSource_0.9.6b.zip"

Thank you very much. That saves me a lot of hassle. Hopefully I can get Elliptic bandpass filter coefficients. When looking through the source code I was seeing something like EllipticOld and Elliptic Lowpass stuff. Generally if something is labeled Old, I assume I shouldn't use that, and there must be something newer. Guess I'll know more by tomorrow if there are any questions related to that issue.

Thanks again.

[thevinn]

C++ seems to be trying to do too much pre-compiler stuff. If I need to write a matrix multiply, I know what data type I need to use. I don't need, nor have any use for one that covers every known data type to mankind

I'm sorry to be the bearer of bad news but C++, with templates, polymorphism, operator overloading, and everything else (including boost, and the standard library), is a spectacular leap forward for programmers in terms of rapid development, and concise expression of complex programming concepts.

Is there a learning curve? Of course there is. But anything worth learning has its price. It seems to me that you have not gone in with an open mind, and instead turned away at the first sight of something radically different from what you are used to. I remember, having learned Pascal, going to a computer trade show at the age of 12 (1984). Some sales guy hooked my mom with his pitch and soon he was telling me "Hey, this new programming language is really big and will become very popular!" To which I responded "Are you kidding me? What kind of idiot would name a programming language after a single letter in the alphabet!"

Proficiency and respect for C++ language features is only acquired after a sufficient investment of time. In the beginning, templates seem foreign, operator overloading seems extravagant, and the C++ standard library seems cumbersome. After a while, you may "connect the dots" and find some aspect of your software that benefits from writing your own template. Over time you end up using more and more of that which you seem to hate. Suddenly boost doesn't seem so bad. Before long, you will not be able to imagine how you lived without C++.

To discard generic programming and C++ features as unnecessary, is only to rob yourself of the joy and wonder that can come from gaining mastery of the language and utilizing it to the best of your ability.

[pj geerlings]

Today's programmers seem to geek out on convoluted complexity.

This has been troubling me for years now - I think it has something to to with creating a "ritual" where none should exist. I'll have to leave it at that 'cause this is completely OT ...

Peace y'all
pj

[kuniklo]

They flat out lie when they say "Go is expressive, concise, clean, and efficient". Were they born yesterday. A simple "Hello World" program shows the difference between Go and BASIC.

Hello world tells you nothing. It's only in larger codebases that a language shows its salt. For instance, a network-distributed key-value store written in Go would probably be 1/10th the size of the equivalent C version and less buggy.

The creator of C++ himself, Bjarne Stroustrup, has said that there's a simpler, cleaner language inside C++ trying to get out. But, for better or worse, it's still the only language that lets you write fast code at any reasonable level of abstraction.

[aciddose]

i've been working with c++ for more than ten years and i've written easily a million of lines of code or more.

i can still read an article and learn new, amazing and cool stuff you can do with the language.

i "know" the language pretty much 90% or so by now, but i don't fully understand every aspect of it or it's possible applications and uses.

i think such a situation is in fact ideal. why put up artificial barriers that prevent you from improving upon the structure of your code? if the issue is purely one of implement ion, use c of course. write it, compile it, forget about it.

c++ shines when you take a second look, or third, or ad infinium.

flexibility, maintainability, scalability to truly massive projects (perhaps nearly unlimited, given the right structure applies at the right time); those are things c just doesn't have.

the reason in most cases c programmers don't appreciate c++ or see the usefulness of it's features is that they aren't c++ programmers. simple as that.

invest a few years to learn the new features if you want to really comment on them - otherwise you're just attacking a straw man.

my rebuttal of the "hello world" attack is always the same.

Code: Select all

c:

{
type *data = (type *)malloc(width * height * sizeof(type));
data[x + y*width] = color;
...
free(data);
}

c++;

{
bitmap<type> bmp(width, height);
bmp(x, y) = color;
...
}

(written correctly, these two blocks of code should generate identical assembly output, but the c++ version can be modified to do other things as well like bounds-checking or otherwise.)

yes, this type of human-readable only the minimum required to convey what the code is doing without any obfuscating gibberish scares the shit out of most c programmers. fair enough.

it's called implementation vs. interface. in c, these are both tied together and mixed up in most code, even if you try to use oo methods the language provides a barrier to true abstraction. in c++ implementation and interface are independent by default if you write real c++, not just c-in-c++.

[Music Engineer]

If I need to write a matrix multiply, I know what data type I need to use.

sure. so do i. but what if i know that i need 2 or 3 different types of matrices? say, for float, for double and for double-precision complex numbers. writing the same code 3 times is very error prone. (see http://en.wikipedia.org/wiki/Don't_repeat_yourself)

I don't need, nor have any use for one that covers every known data type to mankind, which is what leads to large bloated code sizes.

the binary code size inflates only when you actually instantiate the templates. if you consistently use only double-precision real matrices, you'll always instantiate the template like Matrix<double> and the compiler will only generate the code for this type

Also, for some reason this C++ topic keeps centering on templates, as opposed to all of the other annoying things I've listed.

the main thing about c++ vs c is of course object orientation - that is: the concept of classes and objects. consider this:

Code: Select all

double MySynth::getSample()
{
  double tmp; 
  filter.setCutoff(filterEnvelope.getSample());
  tmp = osc1.getSample() + osc2.getSample();
  tmp = filter.getSample(tmp);
  return tmp * ampEnvelope.getSample();
}

this code almost reads like a block diagram in reaktor (or similar environments). very convenient for writing DSP code [side note: per sample function-calls should be inlined]. with C, you would probably use structs and pass a pointer to the struct to functions like getOscillatorSample(struct Oscillator *theOsc) - in which case you would basically do manual object orientation by explicitly passing the "this" pointer.

Maybe a template allows you to not have to duplicate source code, but that doesn't affect the final code size.

this is certainly true. but not having to duplicate source code should not be underestimated. if i should name one single thing that i consider as the root of all evil in software development, it would be duplication of source code.

Since I do most of my time critical stuff in assembly...

OK, looks like you like to program on a low level of abstraction. i respect that. to me, asm code looks unreadable and confusing. quite generally, people seem to consider things as easy when they are familiar with them and to consider them difficult when they are unfamiliar with them.

Today's programmers seem to geek out on convoluted complexity.

i think every programmer has the goal to make things as easy as possible. to me, programming often is like working really hard in order to avoid work. [quote, i picked up from some book, paraphrased]

[kuniklo]

Today's programmers seem to geek out on convoluted complexity.

This has been troubling me for years now - I think it has something to to with creating a "ritual" where none should exist. I'll have to leave it at that 'cause this is completely OT ...

I saw a lot of that when I was doing "enterprise" software. I think it happens because these programmers are working on things that really aren't very difficult so they throw up a smokescreen of artificial complexity to make their jobs look harder.

Low-level realtime audio is hard enough as it is so I'd say anybody that makes that any more difficult than it already is has to be a masochist.

[Music Engineer]

I saw a lot of that when I was doing "enterprise" software. I think it happens because these programmers are working on things that really aren't very difficult so they throw up a smokescreen of artificial complexity to make their jobs look harder.

Low-level realtime audio is hard enough as it is...

we are so lucky

[xoxos]

i don't think it is complicated

my use of c++ isn't much more complicated than the BASIC i was writing when i was 12. i inline practically everything, it's fast.

eg. convolution - holy bloody convolution. it's a bloody simple bloody concept. sure, there may be a faster way to do it depending on the application.

i reckon if a lot of docs used 'bloody' instead of calculus annotation there'd be a lot more bloody programmers is what i reckon. flippin' 'eck.

thanks to everyone who isn't a ponce, you know who you are, bcs i *heart* articulate and knowledgable ppl

[markheath]

This looks a really great library. Thanks for sharing. I might try porting some of it to C# to use with a synth I'm writing, although the heavy use of templates might make it slightly less straightforward than normal.