Online DSP classes

[Digital Larry]

Somewhat OT, but...

I've just signed up and am starting the course work for this class, which is an intro to developing cross-platform effect plugins using JUCE.  You can take it for free or you can pay $20/month and get some extra stuff and a "Certificate of Participation" at the end which you can nail to the wall of your tree house.

https://www.kadenze.com/courses/intro-to-audio-plugin-development

Kadenze offers a whole bunch of interesting classes at the intersection of art and technology.

[Blackaddr]

This looks interesting. Thanks for sharing!

[potul]

Thanks for sharing. Just enrolled. Not sure how much time I will find to go through the content, but looks great.

Mat

[pruttelherrie]

Now I'll have to build a treehouse first :/

[cloudscapes]

If I ever get I2S working with DMA one day, I'll have to give this a peek!

[Digital Larry]

I just finished the intro course.  It is a little hair raising, in that you have to stop and start the session videos constantly to copy the code the guy is writing.  But I got a good feel for how things are structured and a great deal of satisfaction having written an actual AU plugin that worked with minimal effort, even if it was just a chorus/flanger.  And I also got to revisit "why would anyone want to write low level code for DSP?" which was the impetus for SpinCAD Designer.  I actually hate writing DSP code at that level (Spin ASM or C++) because it's all trees and where's the forest?

It reminds me of the words of a well known pedal builder, who sent me a generous donation for SpinCAD.  When the subject of SpinCAD came up in another popular forum, he said something like "we don't use SpinCAD, no I have a team of engineers carefully handcrafting the DSP code that goes into the pedals".  Whether he uses SpinCAD or not, I don't care, it's just the spinning of engineering as "magic" that "most people" can't understand that I find humorous.  However I guess that abounds in this field.

There is fortunately a course in "Faust" which I am now starting.  While Faust doesn't let you draw a block diagram like SpinCAD Designer, it does deal with the concepts of signal processing blocks at a higher level than working directly in C++.  Also it looks like some of the tools will render a block diagram from Faust code so not all is lost.

[audioartillery]

Thanks for sharing the course.  I don't think I really want to get into VST type development, but it's nice to know there's stuff out there for that.

I'm amazed how much people get done with assembly programming.  I did it for a while on the Line6 kit and while it's fun it's incredibly slow to write code compared to C.  Not missing that at all.

[Digital Larry]

Thanks for sharing the course.  I don't think I really want to get into VST type development, but it's nice to know there's stuff out there for that.

I'm amazed how much people get done with assembly programming.  I did it for a while on the Line6 kit and while it's fun it's incredibly slow to write code compared to C.  Not missing that at all.

I started off with the Line6 Tonecore DSP dev kit before I wrote SpinCAD for the FV-1.  I got all of nowhere with the Line6 thing and certainly part of that was an almost complete lack of documentation.  I knew DSP theory from university but didn't see myself doing this in ASM.  Miraculously I managed to sell the dev kit pedal on Reverb just a few weeks ago!  But it does implement  a 2 band EQ so maybe that's what the guy wanted.

Regarding developing VSTs vs. a pedal, the Faust language (I took another course on that after the plugins class) very easily allows you to build apps that run on different targets from the same code.  Faust is a little weird and I probably would never have learned it if not for the Kadenze class. 

I used Faust to QUICKLY make:

a) A digital delay VST which I used with SONAR on Windows
b) An Android app that sounds a bit like a theremin through a wah-wah, all triggered by the phone's accelerometers
c) Code running on a Bela - hooks are there to control parameters with Bela's analog inputs (e.g. a pot)
d) Standalone Core Audio app (sawtooth MIDI synth with effects) on macOS triggered by a Samson MD12 MIDI controller - the CC knobs can easily be routed to any parameter in the patch.

So after all of this, my suggestion for someone who wants to see if they would like developing DSP code, would be to try it on your PC or Mac first, just using your audio interface for I/O.  The concepts are all the same - you have some code that executes once per cycle and interacts with a UI  of some sort.  You can implement a UI using TouchOSC which is cool as it works on the wireless network.

Then if you decide that this sort of thing really floats your boat but you just really need to have a pedal, then you can consider the options from a more informed perspective.  I had thought about the Hoxton Owl momentarily but finally decided (for the time being) to just use an old Macbook Pro with a Behringer audio interface, using Faust to develop the patches and UI and TouchOSC on a small Android tablet to control it.  I haven't done all that yet but Faust especially is a force multiplier because I'm not messing around in C++ code at all.  For the studio it's fine.

[markseel]

Good insights Larry.  Man there's lots of ways to slice this up.  Here's my suggestion (disclaimer I'm very biased) ...

For me there's three aspects of engineering that combine for the perfect storm (or a cool hobby, or an actual competitive product) ... the learning and mastery of programming as a general skill ('C' for me), increasing knowledge and experience of the application of your programming language in the domain of interest (DSP and audio effects, the courses referred to in this thread), and the low level understanding of and the optimization for the hardware and/or system you're deploying on.

If you like doing all three, and if you like coding and experiencing the nuances of DSP effects development (there's lots of ways to do things both the right way *and* the wrong way) then just learn the platform, learn DSP, and write the code.  Like any software project if you carefully build up libraries of low level functions on up to higher level algorithms and effects then, yes I agree, you really can get a lot done in assembly or C.

Writing the code gives you opportunities for optimization and you have full control - tune existing algorithms or create new ones.  It can be quite painful when stuff doesn't work (and really loud ;-).  But it's immensely rewarding when it does work and when you realize how much processing you can fit into an embedded platform with tuning and optimization.  With careful attention to code flow and the use of library functions you can sort of see the signal flow and effect/algorithm chain without a GUI.

Here's the next version of the FlexFX kit (used in the C99).  I'm reworking the C99 for the next campaign and that's taking most of my time ... but I could build some of these kits for folks that are interested.  Shoot me an email (markseel@protonmail.com) and I'll see how many queries I get and how I may be able to fit this option in to the C99 campaign. 

https://flexfx.github.io


Other options:
https://www.diystompboxes.com/smfforum/index.php?topic=121659.0
https://www.diystompboxes.com/smfforum/index.php?topic=121922.0

[Blackaddr]

I'd like to weigh in here as well (Disclaimer: I'm also very biased). I'd also like to point out that Mark's XMOS based projects are very impressive and I have a lot of respect for the work he's done and what he's offered to the community here. This is simply my opinion on how hobbyists can best get started with designing digital effects.

The technology landscape for embedded audio processing has been changing a lot in recent years. I work as an accelerated computing engineer so I deal with all these at my day job.

Available Technologies
- FPGAs - the highest performance solution for embedded processing. VERY difficult to program. Development tools are proprietary and expensive. This is effectively the same skillset as designing customer computer chips. It's takes professionals to do it right, out of the reach of hobbyists for the most part.
- DSPs - chips like Sharc, XMOS, etc. High clock rates with parallel hardware designed for high math computation rates. Very difficult to program well, requires a lot of knowledge about the underlying hardware, but not out of reach for hobbyists. Software frameworks designed to make this easier tend to be very proprietary and not standardized. Either way, each time  you change chips (say from a Sharc to an XMOS) you need to learn a lot all over again.
- Microprocessors - typically Cortex-A. These are used in things like the Raspberry Pi. Very fast (> 1Ghz), multi-core (2 to 8 cores). Need an OS (e.g. Linux) in order to be easy to use. Low-latency in audio applications is a problem. If used bare-metal or with an RTOS for low-latency they become very difficult to setup. Acceleration via NEON, very industry standard.
- Microcontrollers - typically Cortex-M. These things are improving exponentially due to IoT adoption. Some higher performance variants include hardware floating-point, built-in hardware accelerated DSP processing (like IIR, FIR, FFT, etc.) Clock speeds are around 180 MHz for M4F and up to 600 MHz for M7. No need for an OS, super-easy to program if there is a good framework like Arduino supporting it. The DSP acceleration is via the ARM CMSIS library. ARM has become the de-facto standard so it's a great skill to have it.

In a nutshell, tools to program FPGAs with C/C++ are getting better and prices are coming down making them more accessible to the hobbyist but not quite there yet. Cortex A and Cortex M are getting more and more powerful so fast, basically dedicated DSPs chips fill a smaller and smaller niche market and are getting squeezed out and FPGAs push down from the top, and Cortex push up from the bottom.

Right now, fast cortex M4Fs and M7s are capable of doing a lot of real-time audio processing, especially if you're interested in designing your own effects like modulation, EQ, tone circuits etc. and aren't trying to get Axe FX like tube modeling.

As far as being a hobbyist who wants to get into digital effects and modeling, VST is also an option. I do write VSTs but the problem is learning the framework and making the GUI. JUCE is a framework for making both the audio part (VST) and the GUI part all in one. It's both awesome and awful because it makes GUI/VST programming far easier, but is way more difficult than than using a hardware based solution and debugging GUIs is always a nightmare.

For beginners/intermediates who want to get into creating digital pedals IMHO the best solution is the Arduino Teensy hardware using it's Audio library and avoid working with DSP based hardware. Teensy is a tiny-Arduino compatible board that has some decent horsepower unlike regular Arduino boards based on ATMega, etc. The Teensy 3.6 is 180 MHz Cortex-M4F with hardware floating point and some hardware accelerated DSP instructions for things like filtering, FFTs, sine/cosine, etc.

Here's why I recommend the Arduino Teensy with Audio library approach for hobbyists:
- the Arduino community is massive. The development tools are top-notch. There are countless tutorials for all the built in libraries for I2S, SPI, I2C, GPIO, etc.
- the Teensy product has been around for many years and is a very successful hardware platform. It's dirt cheap and isn't at risk of disappearing on you anytime soon. Can the same be said of all these small-volume hardware platform manufacturers?
- You program in C and or C++ with the help of Arduino libraries. You don't have to learn some one-off software framework, or traditional DSP programming which can be very difficult. Yet, you still have access to hardward accelerated functions from the free ARM Keil CMSIS library already included with Arduino Teensy.
- The Audio library added for Teensy makes designing audio effects and pedals stupid-easy (I might make another post on this rather than put in in this one). It handles all the difficult bits regarding transferring and buffering audio blocks, and does it in the background with DMA so it has virtually zero load on the processor.
- (here comes the bias) My open-source BALibrary extensions to Teensy Audio add even more code for abstracting physical controls like buttons and knobs, working with external memory for long delays, as well as adding a few more cool effects.
- my TGA Pro board takes care of all the difficult hardware design stuff like guitar preamp, working with proper low-noise 9V analog voltages, external SRAM memory, etc.
- Upgrade path. Each generation Teensy uses faster and faster ARM processors so your effects will run on newer hardware with little modification. The 4th generation Teensy due out next year will be 600 MHz Cortex M7s. The case for using traditional DSPs chips like Sharc, XMOS, etc. gets lower each year as ARM processors are on an explosive growth path.

[Digital Larry]

Note that Faust already has a port for Teensy - https://faust.grame.fr/doc/tutorials/#dsp-on-the-teensy-with-faust

[Blackaddr]

Note that Faust already has a port for Teensy - https://faust.grame.fr/doc/tutorials/#dsp-on-the-teensy-with-faust

Cool! Didn't know that!

[Digital Larry]

Some kind of graphical tool is undoubtedly the easiest way to start.  Many people may find all their needs met by that.

I bring up Faust for a few reasons,
#1 mostly it's on my mind as something I want to study and get good at using.

#2 It also has many synth (analog emulation, wave playback, FM, extensive physical modeling) library functions, so for example you could see building a pedal with MIDI drum machine/bassline features.

#3 there'a a whole set of guitar-oriented library functions - tonestacks, tubes, etc...
https://github.com/grame-cncm/faustlibraries/blob/master/tonestacks.lib
https://github.com/grame-cncm/faustlibraries/blob/master/tubes.lib
https://github.com/grame-cncm/faustlibraries/blob/master/vaeffects.lib

#4 There are MANY more filter building blocks and functions... you can say "give me a 10th order elliptical low pass at 123.45 Hz" and boom there it is.  You'd have a hard time making something like that out of 2nd order sections.

#5 It uses a lot of the Synth Toolkit C++ classes.  If you are writing C++ code then these give you a lot of power.  Just watch the licensing details.
https://ccrma.stanford.edu/software/stk/classes.html

Then on the downside:
a) it's yet another language to learn

b) it's "functional" rather than "procedural" - there's no "if/then/else" structure - you can do those things but it has to be done a different way, just one example.

c) it's bizarre to look at - I took a class and I don't immediately grasp most of the examples I am looking at

d) It probably has significant generated code bloat to handle all that abstraction.

[Digital Larry]

Note that Faust already has a port for Teensy - https://faust.grame.fr/doc/tutorials/#dsp-on-the-teensy-with-faust

Cool! Didn't know that!

It would be very interesting to see whether you could adapt the Faust port to recognize your additional memory for delay.

Also take note of how they have (in the case of the Bela port) adapted the Bela hardware specific items into the syntax, e.g. to allow a virtual "slider" to be controlled by any of the 8 pots, buttons can be controlled by switches, etc.

https://github.com/BelaPlatform/Bela/wiki/Compiling-Faust-code-for-Bela#interfacing-with-belas-analog-and-digital-pins

It's all open source and unlike some of the things I've been involved in, the Faust mailing list is fairly active and I have been able to interact directly with a few of the key developers of the product.