Coursera course: Audio Signal Processing for Music Applications

  • I just got an announcement about this course: https://www.coursera.org/course/audio

    It uses Python and looks neat. I need another project like I need a hole in the head, but I might sign up for this. The Coursera course on ChucK was a lot of fun and quite effective.

    (I signed up. The first week is already over. I'm having trouble watching the first lecture, but it may have something to do with a backup I'm running. Downloading the videos directly works fine.)

  • i\m assuming this isn't going to help with learning how to code for the Aleph? That's all in C right?

  • learning to code in any language will help you learn to code!

  • but isn't the syntax really different? I mean I know jscript to a passable level but it isn't helping me working out where to start with the aleph github?

  • What brian is saying: learning the concepts of programming in any language will help you to code in any language..
    In JS e.g. it's the concept of variables, loops, functions etc. which you'll find in any language.. Then there's OOP (object oriented) in there too.. In C it gets much deeper of course, with data types you need to handle yourself, pointers, preprocessor stuff, just to name a few..

    Me personally I found java (nothing to do with JS!) to be a good intermediate between JS and lower level stuff like C/C++/Obj-C regarding complexity, but that's more on the OOP side.. C is procedural.. Still, you could just ignore or neglect the concept of OOP in a language and have procedural..

    In any case, learning to code means: write code and make the mistakes yourself!

  • we'll have DSP, bees op, and general app development how-to guides by the end of the month. this will provide a framework for getting into aleph development.

  • @tehn awesome news!!!
    @raja I think at this stage I'm not expecting to be going headlong into DSP algorithims, though I'd love to try and create a ring modulator that could be added into Lines.

  • Ok, how would I go about applying those approaches in C for the Aleph though?

  • so cool

  • @raja this is totally amazing. It's opened up a lot to me of how this things fits together (and learning obvious things like .h is a header file!)
    Something else I still don't get is how these functions are called. They all seem to be within this 'void' function, is this something that is repeatedly called at audio processing rate? (this is what 'interrupt' level is right? or am I on completely the wrong track.. googling 'void' and C is pretty hard to find useful results!!)

    How to create the oscillator seems harder. Would seem that I'd need to bring something in from Waves as there are no oscillators in Lines as far as I can see (unless I use one of the physical inputs). @zebra might be able to chime in here.
    Would I be heading for a dead end if I just started putting things like
    #include "osc_waves.h"
    inside the Lines code?

    Is there a way to test these experiments as I go along on the computer? or do I have to continuously compile and transfer to the Aleph?

  • this looks great - thanks for the heads up. joined

  • there is too much here to really respond to.

    i said something on here:
    http://monome.org/community/discussion/18140/is-it-possible-to-build-a-ringmod-on-the-aleph

    as far as adding oscillators to lines, yes you can use the oscillator classes in aleph/dsp. the ones in waves are very lightly edited from those. (i tried a lot of other experiments with them that didn't really work out.. like interleaving the state variables for multiple oscs in a hardcoded bank and looping over them "sideways" ... still might give that another try as i think it would be quite a bit faster.)

    be aware that by adding stuff you will probably hit the limit of CPU pretty fast and have to re-code things to be more efficient, or drop some features (like the full 4x4 matrix mixing, or filters, or parameter smoothing.) it's pretty obvious when you hit the limit because it will start dropping every other frame or something very like that.

    as far as interrupt vs. main loop: in the aleph DSP, everything happens on an interrupt. all DSP classes are run per-frame. yes, there are 4 samples per frame. (it's a standard usage: a "frame" occurs at a set rate.)

    this is really not very efficient and as soon as time allows i am going to implement buffering, and make buffered variants of all the DSP classes, so that audio processing can be done in the "background" (on the main loop) and copied to the output busses on interrupt, as raja describes.

    and yes, these are C programs that are cross-compiled to blackfin machine code. you need to compile them on your machine and then either put them on the sdcard to use from bees, or roll the binaries into an avr32 program to flash to the aleph controller in place of bees.

  • if anyone is seriously interested in writing aleph DSP modules, *please* i beg of you, look at aleph/modules/mix/mix.c in the github. it is explicitly intended to be an informative starting place. i wrote extensive code comments which answer many of these questions.

  • i'm also going to second the very true statement that programming is programming regardless of the language, and python is as good as any.

    but there's a grain of salt on that, which is that C programming is its own thing with many traps.

    totally indepenedntly of understanding signal processing, you need to have a basic understanding of C concepts like pointers, types and type qualifiers, structures, and how the compiler traverses files, in order to extend the aleph firwmare or any other C project.

    ( fortunately, i actually think C is much much easier to learn than C++, for what it is worth. the language spec is really not that big. and on the aleph we are not using standard libraries, which is a big chunk of the usual learning curve.)

    i really recommend "the audio programming book" by boulanger/lazzarini, which effectively bridges the two topics (and many auxiliary ones like GNU make, many popular plugin formats, other stuff.)

    f richard moore's "elements of computer music" is a now-venerable classic that also contains a lot of clear, working C code. including an FFT and phase-vocoder implementation if you want to go there.

    to be honst i think JOS is a fantastic scholar but... i dunno... coursera syllabus seems to go pretty deep into his specialist theoretical fields. understanding the theory of the DFT is not at all necessary to implement basic audio processing or synthesis. same goes for sinusoidal+residual model, etc

  • Thanks for the tip about the Boulanger/Lazzarini book!

    I'm watching the 6th-week lectures for this class now. It's very good. The lectures and assignments are pretty substantial, but don't get nearly into the depth of JOS' online materials. Once Prof. Serra goes over e.g. the DFT, you subsequently can treat it as a black box and just use it from numpy or the sms-tools provided for the class. That said, I'm very glad I'd read Musimathics and had a decent understanding of the Fourier transform already.

    One point about this course (so far) is that it is not presenting real-time audio signal processing. I suppose that in some cases (?) Python would be sufficiently fast to do the job, but that's not how the material is presented, nor are the assignments set up that way. So to make the leap from this course to writing DSP code for the Aleph would require not just coming to grips with C, but also thinking about what can be accomplished in time with the given resources. (I'm not sure how much the hardware constrains what can be done here, but I think I've seen comments here and in the code suggesting that timing can be tight.)

  • i'm actually enjoying this course (although i'm way behind, only on week 2). python is actually pretty fun