Best programming lang for writing digital fx

eraserhead

Member
Hello.

I'm just Getting into coding and
And I'm digging it but I need a starting place I would love to write my own digital effect algorithms. As I'm a big fan of the older lexicon,eventide and TC units.I've been messing with Python and swift.

Any input would be great. Thanks
 
Well, you want extremely low latency, so that means coding as close to the bare metal as possible.

Python and Swift aren't there (they're pretty high level, and "far away" from what you'd be doing), but they may be starting points to get you in the mindset of problem solving.

For accurate modeling, you want a math heavy background, too. Electrical Engineering (EE) is practically a must as well.

Then, the course you want to set sail on is DSP - Digital Signal Processing. Here's a place to start, by the guy who basically "wrote the book" on DSP, as it were:
http://ocw.mit.edu/resources/res-6-008-digital-signal-processing-spring-2011/index.htm
 
Thank you for the info

I just started to learn code and was thinking of writing an effect plugin first before I get into DSP.

So I still need a good starting place language wise for eventually learning to write an effects algorithms.

Thanks
 
Writing a VST is pretty different than getting to the DSP level. I thought you wanted to go down the DSP route since you mentioned Lexicon and TC.

I would suggest going with C++ and using Steinberg's VST SDK for your first trip. A lot of people have used it to get their feet wet. You'll need a (free) developer account to download it:
http://www.steinberg.net/en/company/developers.html

I'd suggest using Visual Studio Express for your dev work, at least as a start.

Also worthwhile would be getting an account on github for revision control / source code management. This will be especially useful as you progress, as you'll be needing to share your project with people for help ;)

It's going to take a lot of learning... it's been a few years since I've used that SDK, but I think it had some example code, at least in the documentation (which you'll want to spend an enormous amount of time reading). I'll have to check some other time, but I may still have links to other references and forums that are gold mines for resources.
 
I would take a look at Juce (juice.com), not that it has DSP libraries (not as far as I know, it has various filters, though) but because it has a lot of other functions and classes you most likely need for building audio apps and plug-ins. The framework is in C++, so yes learn C/C++ for the time being. Swift will get there as it has all the needed parts (LLVM compiler) for low-level optimization works, we might argue about ARC but there are options to use C pointers directly.
 
Selta and ksandvik

Thank you for all the info it looks like C++ it is and swift for the iso apps.

As far as writing a plugin I was thinking that a good step to get my feet in writing an effect algorithms.. DSP is something I'm thinking about as well in the future.

I'm only on my 5th day of learning code so I'm figuring out the best route and order to do things. Let me know if this order would work.

1. Find the best programming language for coding digital effects. Looks like C++
2. Study my ass off on that language learning the basics and beyond.
3. Start building simple effect algorithms.
4. Building more advanced algorithms.based on famous algorithms.form the rack gear I listed above.
5. Starting thinking about DSP at this point.

Thanks again guys
 
At a high level, that's a decent plan yes. "Best" is subjective, and in part (or in whole) also defined by the end goal. Sometimes C++ is best, other times digging down into Assembly is. For all around, I recommend C++. It's imperative, object-oriented and generic. You can get pretty low level with it as well.
Part of your step 2 needs to be making other, smaller programs. Since you're gunning for audio and signal processing, maybe start with something dead simple like a featureless MP3 player. Then, iterate on that and add small features... like, EQ. But, a large part of this will be learning to think like a programmer, finding multiple solutions to problems, refactoring algorithms and code blocks, etc. etc. All of those things are language independent. You'll learn C++ cyntax, but the skills you acquire along the way will translate into other languages... eventually, the syntax won't matter a whole lot, and you'll be able to add other languages (at the basic / intermediate level) with only a bit of effort.


Basically, have a very clean plan of attack. Maybe see if your local community college (or something like udemy, MIT online etc) offer courses that will help you along. Register on forums, ask questions. It's going to be a long journey until your even writing the first line of code for your signal processing. :)
 
Thank you for all the help you guys are giving me.

The few friends that I know that program say the something about C++

But there not audio guys so I have to look at all options..

So time to study up.

Thanks again
 
If you avoid all the craziness features C++ introduced in 3.0 (maybe templates are OK) then you are fine, keep it simple. There's been a trend just now in programming where interfaces are preferred to subclassing (like in Swift.)

Basically you need to grok that C/C++ is basically an assembler front-end where you have access to addresses and you need to think twice when you access those, that and constantly thinking about memory, should I release memory now and why (again Swift removes that.)
 
I'd rather get waterboarded than suffer in/with C++. :eek:
I'd actually like to hear the reason(s) behind this?

Python is a fine language, and an OK method to get a person's feet wet. Python, though, is interpreted, not compiled (hence, runs slower == death in real time audio processing). One immediate thing that I think would be useful that Python can't do (but, C++ can) is static polymorphism. The other thing about Python is that often times, the libraries are just invoking lower level C++ anyway... :)

I will contend though that C++ will have a steeper learning curve. But, if the end goal is real time audio processing, I can't think of a better language to start learning now, personally. If that end goal changes, it's likely the language of choice will, too.
 
I'd actually like to hear the reason(s) behind this?

Python is a fine language, and an OK method to get a person's feet wet. Python, though, is interpreted, not compiled (hence, runs slower == death in real time audio processing). One immediate thing that I think would be useful that Python can't do (but, C++ can) is static polymorphism. The other thing about Python is that often times, the libraries are just invoking lower level C++ anyway... :)

I will contend though that C++ will have a steeper learning curve. But, if the end goal is real time audio processing, I can't think of a better language to start learning now, personally. If that end goal changes, it's likely the language of choice will, too.

Yep, and I'm sure C/C++ will be around for another 25+ years.
 
Yup, it does. I agree that there are a lot of things that can be done very poorly in C++, though this is also true of most languages (obviously, C++ can wreck a lot more havok). As a guy that does bare-metal programming for a living, and always work with very capable teams, we all keep away from those pretty easily. In fact, one of the main CM packages we use (Ansible) is written in Python, too.

Matlab is nice, I've used it quite a bit myself. I guess my problem is that I'd rather not send OP down that path, since it's a bit divergent from their stated goals. When they start going non-linear, the best you can do is a gross estimation. While may be "good enough" for the academic purpose, I'm not sure it'd be suitable in the real world :).

In *any* case, the OP is going to need quite a bit of math :)
 
Matlab is nice, I've used it quite a bit myself. I guess my problem is that I'd rather not send OP down that path, since it's a bit divergent from their stated goals. When they start going non-linear, the best you can do is a gross estimation. While may be "good enough" for the academic purpose, I'm not sure it'd be suitable in the real world :).
That is because Matlab is not a programming language in the classical sense. It is more a mathematical toolset designed for analytics and reading/visualizing sensor data. That's why it's the default in labs and science applications. This has nothing to do with Matlab being "just good enough". It is the best in it's field (visualizing and processing data). The programming in Matlab is the means, not the end.

Now, you did ask why C++ is so bad. It's major problem is that it is a dangerous language (pointer arithmetic, not detecting integer overflow, no garbage collection, null pointers are permitted, etc.) that encourages programming mistakes (including memory leaks, random overwrites of memory, crashes, etc.) that can be extremely painful to debug/fix (hence Valgrind), particularly in multi-threaded code.
Au contraire. The fact that C++ doesn't take your hand with all this stuff leads to better code, not worse code. That's why C++ is the industry standard.
Especially garbage collection is a horrible thing to have when speed matters.

It's the bike without the training wheels.

Then again, I can see why this topic is controversial. It depends what you regard as better code. You probably prefer the "shorter code = better code" paradigma, while I prefer "complete code = better code".
 
Last edited:
Here's a nice book on audio plug-ins in C++:
Amazon product ASIN 0240825152
Here's a tip for C programmers who are learning C++. In addition to pointers, C++ has references. Pointers and references are basically the same thing, with two differences. First, a reference can't be null -- it always refers to some object. Second, if x is a pointer, you write *x to access its contents, but if x is a reference, you just write x. And similarly, if x is a pointer, you write x->abc to access field abc, but if x is a reference, you write x.abc.

You can convert a pointer to a reference by writing *x, and you can convert a reference to a pointer by writing &x. Neither of these conversions actually "does" anything -- the compiler doesn't generate any code for them. In theory, when converting a pointer to a reference, the compiler would check that the pointer is non-null, but most compilers don't.
 
Start with simple plug-ins. Plug-ins are a really good place to start as you 1) Already have a Mac or PC, 2) get to produce something you can use while you learn, 3) the development environments are fairly stable, 4) the development environments have great debugging tools, 5) there's lots of help and tutorials on the internet.

If you're on a Mac then Objective C & Xcode are fine to experiment with - stick with the ecosystem you're comfortable with, if it's Mac then stay put for now.

Here's the Audio Unit Programming Guide which is a good place to start and has a tutorial for a mono tremolo. Simple and gets you thinking about effects, basic GUI and coding.

https://developer.apple.com/library...n.html#//apple_ref/doc/uid/TP40003278-CH1-SW2

A simple delay is a really easy 2nd or 3rd project. Hint: It's an array of audio samples. If your sample rate is 44,100 and you want a 1 second delay then your array has 44,100 elements. Your delay loops through the array saving the incoming sample at the current array position [n] and plays the next element [n + 1], increment your counter 'n' and do it again... when you hit the end of the array set your counter to 0 (the beginning of the array) and keep looping.

The first time through the array your array is empty so you replay nothing, but in subsequent passes through the array the sample at [n + 1] is the sample that came in 1 second ago (technically it's 1 sample less than 1 second, unless your array size is 44,101 elements).


If, after a couple simple plug-ins, you find you have a taste for this stuff keep going. If you want to try cross-platform try JUCE. If you want to go deeper then look into coding for hardware devices like the Axe!

Good luck, hopefully we'll seen you soon on the AxeFx's credits page!
 
Last edited:
Back
Top Bottom