#45

Not sure if a discussion of open-source module firmware is maybe a bit orthogonal but I was reminded today that 4ms has published source for several modules (notably Spectral Multiband Resonator, Spherical Wavetable Navigator, Dual Looping Delay), all in C and for STM32. A lot of this of course focuses on UI rather than “audio programming” proper, though that’s also pretty interesting.

2 Likes
#46

Hoping this is not too tangential for this thread, but where could one start in practically and efficiently learning STM32 programming with an eventual goal of using it for making audio hardware things? Mainly asking so I don’t end up needlessly reinventing the wheel and making things too hard for myself (I have a tendency to do that).

I haven’t touched it at all yet, but I recently got this breakout board as a cheap starting point. Now I’m wondering if I’ve gone into the deep-end too soon and should’ve gone with a discovery board or something.

I’ve also seen this blog post from Tom Whitwell and I have a Clouds currently in a box somewhere, so I also have a fully functional thing with knobs I could use to play around with this stuff, too.

1 Like
#47

i’d say it kinda depends if you want to use the STM HAL, or something else, like the Mutable HAL stack. if the latter, you’re good to go with a Clouds i think. but i dunno how easy it would be to adapt to a raw breakout board like that one.

4ms and whimsical are other companies whose repos you can look at, i think both build on the MI work.

if you want to use STM HAL, it’s probably easiest to get a Discovery board and use the stack of stuff maintained / supported by STM. i recently had a fine experience with stm32f746g-discovery which is pretty cheap (though not $14 cheap!) and has tons of peripherals that are helpful for prototyping. (like, a touchscreen.)

i’ve done two audio projects with STM HAL. a few years ago someone else set it up, last year i started over myself. it was, frankly, a total pain. unfortunately, both projects are proprietary… :see_no_evil:

in a nutshell, i managed to build a linux project by using cubemx to figure out some peripheral configuration, openSTM (aka System Workbench, a customized Eclipse) to clone demo projects and get things going, and then translated everything into CMake / Makefiles with the standard arm toolchain / GDB. this was all a huge drag and i would love to see a better way, but at least it’s possible with open source toolchains.

honestly if you are worried about spending time in rabbitholes and just want the quickest path to coding something, that’s probably just getting a discovery board and using the System Workbench stack on windows.

thing is, the HAL abstracts so much stuff that you’re not really dealing with the instruction set or the MCU architecture. that’s probably fine; grokking the HAL and the examples will force you to read plenty of the arch documentation anyways, which is a baseline for rolling your own stack or whatever.

also, @csboling is on the nose with the observation that the stm-specific stuff and the audio stuff are basically completely orthogonal. all the painful crap is about configuring timers, memory, I/O, blabla. the audio stuff can and should be prototyped elsewhere first.

5 Likes
#48

This I think bears (over)emphasizing for the broader question of “how do I develop/extend module firmware”. Virtually anything you can should probably be prototyped elsewhere first. Even if you have an in-system debugger you’re reasonably happy with and other developer conveniences, it is still usually a much better experience to have an operating system yell at you when you inevitably access memory out of bounds, rather than an embedded target just crashing or corrupting unrelated parts of the program or whatever, and the compile/check/revise cycle is almost certainly much faster in a desktop programming environment than when you have to reflash the target in between. The Teletype code is a nice example of this – all the ops and language evaluation logic are in src/ so you can run unit tests/debug, all the UI and hardware interaction stuff is in module/.

4 Likes
#49

Just to clarify & extend @zebra’s points above:

The Just Friends project was initially prototyped by extending the 4ms SMR. It was a not-terrible place to start & helped me to understand many things which now seem ‘obvious’ but were initially confusing. JF still uses the older (and now unsupported) stm32 SPL.

The crow project uses the stm32 HAL libraries and was built from the ground up (with some drivers inherited from the W/ firmware). The HAL does it’s best to abstract away any notion of the MCU instruction set, and I agree not great but is now quite solid.

To the topic at hand, I personally find the interesting part of ‘lower-level audio programming’ to be the way in which you handle the environment, and construct your signal processing graph. The building-blocks which actually do the signal processing are available in numerous permutations around the web. I find myself rolling my own often, and it seems like many folks do the same in order to fit a given interface. Math isn’t my strong point, so I shy away from complex signal processors, and focus more on the composition of simple blocks.

7 Likes
#50

You could also check out Eric Brombaugh’s STM32 examples: http://ebrombaugh.studionebula.com/synth/index.html

1 Like
#51

A few years ago I got soundpipe code working on a stm32f4 discovery board.

It probably isn’t the best code to look at because I didn’t know what I was doing. But I did get sound coming out of it.

3 Likes
#52

More math-related than programming-related, but I thought I’d share as it’s been a great resource to me. Physical Audio Signal Processing, by Julius O. Smith II from Standford. What I love about it is how complete it is, how clear the mathematical definitions are put, and how embedded hyperlinks allow you to jump to definitions of pre-required math.

8 Likes
#53

this is a KILLER recommendation, I’m very excited!

1 Like
#54

His book on Fourier analysis/the DFT is great as well!

3 Likes
#55

Hi there!

I’m trying to make myself a plan to learn theory for audio processing. As a result, I want to be able to program some audio effects or virtual instrument stuff in a form of VST plugin (I saw frameworks like JUCE which can help with UI/API plugin stuff and focus on implementation) or external addons (not patches) to the PD/Max.

I’m a programmer myself (not yet related to audio processing though), so I don’t really need an introduction to stuff like how to start programming.
So I need to learn theory more, but some programming examples will be helpful anyway.

There are plenty of interesting books, but many of them are heavily biased on some topic. For example, there is https://www.amazon.com/Audio-Programming-Book-MIT-Press/dp/0262014467, which looks interesting but providing all examples in the form of C programs, which I don’t really want to use. They are not like pseudocode examples but complete implementations which are not useful form to provide theory stuff.

“The Theory and Technique of Electronic Music, Miller Puckette” also looks interesting, but I wonder if the explained theory will be useful for understanding how to implement it, not only in the form of PD patches.

I found many recommendations for “The Scientist and Engineer’s Guide to
Digital Signal Processing, Steven W. Smith”. It is not really audio-related though. But, maybe it is an advantage to grasp some math before doing audio-specific stuff? Is information in this book heavily-related to the audio processing routines?

So, can I start with http://www.dspguide.com and take something audio-related after/in parallel, or maybe there are some better books or resources?

1 Like
#56

I can’t exactly vouch for this because I’ve only just begun, but I’m working with this book: https://greenteapress.com/wp/think-dsp/ because the only programming experience I have is with python. Interested in other responses to your post as well.

2 Likes
#57

some solid recs came out of this thread

https://llllllll.co/t/dsp-book-recommendations

I think pretty much all of the ones mentioned were fairly theory oriented even if there were C examples (which I assume would still be pretty relevant for plugin or external dev)

1 Like
#58

both the miller puckette and steve smith books are free online…

smith is a decent reference of theory and tehniques. it is written in a folksy, “practical” style that i don’t actually love (find it a little bloated, plus it covers a lot of topics) but might work for you. what it doesn’t provide is the conceptual glue regarding how DSP techniques translate into musical tools. (and code samples are in BASIC, gah)

that glue is what puckette is all about.

it is useful. whether it is most efficient depends on your preferences i think. personally i find it harder to grasp a PD patch than other kinds of description.

i agree with your assessment of lazarrini. (see other thread.) it is the textbook for an undergraduate course for novice programmers, and reads that way.

free resources: absolutely go download puckette’s book, and keep julius smith’s site bookmarked as a reference. (buy the printed editions of his books if you want to have it on hand.)

my recommended books would be:

  • stieglitz “DSP primer” for quick and to-the-point math reference
  • zolzer “DIgital Signal Processing” and “DAFX” for specific ideas on musical tools implementations. the latter has a great bibliography
  • will pirkle for very clear and direct C++ examples and recipes. this might really be the most actionable if you want to go straight to making stuff in JUCE.

these are alll a lot more focused than the steve smith book.

note that for zolzer and julius smith the lingua franca is MATLAB.

11 Likes
#59

More recently, Julius Smith also has written quite a few things written in FAUST. You can find these as supplemental material on his various textbooks. He has been a large contributor to the FAUST standard library. If you look at the FAUST code he writes, he will often cite where the algorithm comes from.

1 Like
#60

I recently got a clone one of these https://www.seeedstudio.com/Ai-Thinker-A1S-Wi-Fi-BT-Audio-Development-Kit-p-3160.html from ebay for not much money.

It has a build in audio codec with headphone out and line inputs and is supported by Faust here…
https://faust.grame.fr/doc/tutorials/#using-the-esp32-c-development-environment

If you wanna play with audio programming outside of the PC, this is an easy and cheap way to go about it. The board has spi on headers so adding pots and external CV inputs should be doable that way.

3 Likes
#61

This looks like a neat platform to experiment with – thanks for sharing that

#62

I am interested on implementing some ideas I have for synths/effects. I know how to code but nothing very low level (only python, Mathematica).

Already have Ableton suite which comes with max4live. So Max (& m4l) is what I have been thinking to use but Faust also seems to get a lot of positive reviews. Pyo also exists which is python wrappers for csound(C?). Supercollider seems interesting too with all of the Norns happenings.

Feeling a bit overwhelmed by the options and looking for suggestions on which to go with?

#63

TL/DR: i’d recommend playing with Max if it interests you and you haven’t yet.

mathematica and scipy are ideal places to experiment with low-level algorithms.

Faust is a great tool to learn for a specific sort of task and mindset: 1) extend capabilities of environments like Max, 2) specify algo specifically as a “functional audio stream.”

i blathered more, and repetitively, under this triangle:

i don’t think there are any wrong answers. if you are comfortable in mathematica / scipy, those are ideal environments for working out low-level algorithms succinctly and with many analytical tools attached.

C/C++ is of course the most portable and performative way to make a procedural implementation of most DSP algorithms.

other things you mention (supercollider, csound, max) involve constructing more complex programs out of DSP building blocks that can be low level (arithmetic, storage) or high level (oscillators, effects.) they are all fun, powerful and well-documented.

Faust is a little different: it’s not an execution environment like the others; it is a sort of meta-language taking a functional DSP graph and producing optimized C/ASM code; which in turn can used as a building block in Max/Csound/etc, or in standalone programs. Faust is a great tool if what you want to build can be easily expressed in its graph language (which isn’t always the case.)

4 Likes
#64

Thanks for all the insight!

Faust sounds really interesting but like seems more than I really need and C++ seems like too much to take on right now.

It seems I should be able to implement what I am looking to in Max, at least everything I have in mind now. I’ll start playing around in Max see if I can get it to do what I’m after.