I’ve been making a few hardware audio effects using the Teensy dev board, and have shared some of the results here. Due to lack of debugging tools on Teensy I found I spent ages trying to track down issues that would have been trivial with proper dev tools, so I’m considering doing the prototyping by writing a plugin using real dev tools, and then move to the Teensy when I know my DSP code is sound.
Can anyone recommend a good approach? I’ve been considering using either JUCE or writing a native Audio Unit. Ideally I want something as low-level, and close to the Teensy audio library as possible.
Thank so much for this @zebra! JUCE it is! I’ve never done any fixed point maths in Teensy, only standard floats, so unless the libs hide this from you (which seems unlikely) I think both the 3.2 and the 3.6 have floating point units?
I’m quite excited about it, as now I’ll get a software version and a hardware version…
I think both the 3.2 and the 3.6 have floating point units?
negatory. had to look it up to confirm my memory, but indeed: teensy 3.2 uses freescale MK20DX256VLH7. the ‘D’ means that it lacks a hardware FPU. the float version is MK20F… something. this is not at all easy to discover, its buried in section 2.3 of the datasheet.
teensy 3.6 has got an upgrade to K66FX1M… something, which does have a hardware FPU (datasheet). hooray!
yes indeed, you can still perform floating point computations without dedicated hardware, it is just much slower. maybe by a factor of 10x or 20x. i found it is better to stick to fixed point on teensy 3.0-3.2, otherwise your power is a bit limited. if you do want to go with (soft) float math you might want to play with the related arm-gcc options to speed things up.
Ha - that is interesting! Fixed point math sure is a lot of hard work.
Another thing I’d mention (again) is that faust is an incredibly fast language to work in for prototyping DSP algorithms, once you get your head round ‘functional’ DSP. So that might be worth looking at. You can write all faust code under linux/jack - greatly speeds algorithm-level debugging. Then once you’ve got the faust code for you algorithm cooking, you can link the faust objects into the rest of your C/C++ program…
Well, this approach has been highly productive for me anyway!
speaking of optimization, i should say that my example is not so good, in that you probably want to define your process function to operate on a whole block of samples, with frame count as argument. i omitted this for space/clarity with the fixed/float casting.
another advantage of the faust approach - you can ‘think’ in sample-by-sample like the way aleph DSP code reads, whereas the code compiles down to highly efficient, (completely unreadable) block-processing…
I finally got around to doing this, and it works a treat. I now have my Teensy effect running as a VST/Audio Unit using the Juce API. I can highly recommend Juce, very easy to get started with, and the forums were very helpful. https://github.com/cutlasses/TeensyJuce/