How can I run gen~ patches on a teensy?

[zebra]

@L4COUR

So…can i run gen~ code on a teensy microcontroller, and if so how?

good question. let’s discuss.

[zebra]

here’s my initial, kinda high-level answer:

@zebra

• up front, you need some moderate experience with c++ programming.
• send the exportcode message to a gen~ object. this produces a .cpp file, a .h file, an a gen_dsp folder which contains some dependency headers.
• the generated header and source files define a DSP State struct and some functions that operate on it. in particular there is a perform function that accepts a State and some arrays of sample I/O buffers.
• the teensy audio library has a base class called AudioStream which embodies the interface to the teensy audio HAL. this class includes a virtual update function which operates on a block of samples.
• you subclass AudioStream , use the perform function defined in gen_exported.cpp within your AudioStreamSubclass::update() function, and pull in the needed dependency headers that the gen export tool has “conveniently” consolidated for you.
• then you decide WTF you wanna do to connect your hardware with your patch.

this process is a bit finicky and tedious, with some juggling of toolchains (maybe you use arduino, maybe not, &c). so when folks like the Bela or electro-smith developers put work into making that tooling nicer, we should definitely give them due credit. AFAIK no one has made a nice tool to just seamlessly take gen~ output and produce, say, a sketch folder for teensy that you can run right away.

it’s not as simple as it might look, because at some point you do need to make decisions about how to connect your patch to the host environment, or it’s not very useful.

maybe someone has actually attempted this project recently! (i have exported gen~ to various environments, and i have written teensy audio modules both with and without arduino, but i have not actually put the two things together.)

maybe there are huge gotchas that i am not yet aware of!

[L4COUR]

waow thanks for that very elaborate answer! yes it seems super complicated to juggle all of these different files and folders with each other. I am really looking forward to not only making this process hopefully more accessible for people with a more limited understanding of advanced programming. I hope that not only be the process made more simple, but also that the documentation will be made very beginner friendly aswell!

[simonvanderveldt]

I have no hands-on experience with any of this so maybe this makes no sense but wouldn’t it be easier to use Faust to write the code and then use faustgen~ to use it in Max?

Because the code itself is written in Faust the process of compiling it for different platforms is already taken care of (see for example https://faust.grame.fr/doc/tutorials/#dsp-on-the-teensy-with-faust) or should at least be a lot easier than the process as described by @zebra. Or does this make no sense?

[zebra]

oh yeah, personally i agree that integrating Faust-generated code is a little easier.

for one thing, there are the many existing build scripts like faust2teensy. these are authored by many different contributors. sometimes i find that they work out of the box, sometimes they require enough fiddling and toolchain setup that it doesn’t seem worth the trouble. TBH i never really use them because it’s simple to roll your own template and tell faust to use it during compilation.

but even if you don’t use one of the build scripts, faust-generated code itself has very minimal dependencies, and control signals are easily plumbed in (they are just pointers to floats in the DSP module.) so yeah, i agree.

to me, the main purpose of gen~ is to conveniently add arbitrary single-sample process loops to max patches. and i haven’t exactly seen a lot of super weird or complex gen patches that couldn’t be easily created in faust or supercollider or with your favorite C audio library.

there’s a pereception (reality?) that dataflow paradigms are easier to work with than functional or imperative code. to me, the math is just as hard either way. but hey, people keep asking about it.

i’m curious for someone to try gen -> teensy (it shouldn’t be a big deal honestly, steps for integrating faust code without a build script are pretty similar.) i’m not really in a hurry to try it myself…

[arev]

Unfortunately I’m still on the way of getting moderate experience with cpp, but I’m actually trying to port a Griesinger type reverb with interpolatable allpass delay lines which I’ve built in gen~ (after struggling multiple hours in FAUST to do that - if you ask why anybody would try to use gen for patching instead of faust) to the teensy audio library.

Your description really sounded much simpler to follow than it is, because as soon as I tried finding any similarities in the example code from Paul compared to the exported cpp I miserably failed.

Could you, as somebody who already has experience with both the audio library and exported cpp gen syntax, anyhow try to elaborate the process a little bit more? I really don’t want to give up…

already thanks a lot for your help.

[zebra]

like i said above:

@zebra

(i have exported gen~ to various environments, and i have written teensy audio modules both with and without arduino, but i have not actually put the two things together.)

i don’t need gen~, and while i love teensy’s i generally don’t use the arduino environment on them. so i don’t have a template for you. i like faust and like i said above it’s easier to integrate because you can tune the output code structure to be very minimal, or to work directly in your audio framework (e.g. making a new faust target template which subclasses teensy AudioStream.) i’d be happy to go through the process of gen->teensy myself and document the steps, but honestly i just don’t have time right now or in the immediate future.

if you’re just getting started with c++, this might be a tough project. if you want to do it, my suggestion would be to first experiment with making a custom audio object in the teensyduino environment, as shown here:
https://www.pjrc.com/teensy/td_libs_AudioNewObjects.html

it can be something very very simple, the point is to become a little familiar with the environment your porting into before you begin the actual task of porting exported gen~ code. if you have trouble with that step, fee free to ask about obstacles, and if you get it working, feel free to ask about next steps.

also if you want to share a gen~ reverb patch i can probably port it to Faust quite easily.

[arev]

Alright thanks I’ll definitely give that a try

@zebra

also if you want to share a gen~ reverb patch i can probably port it to Faust quite easily.

Wow yeah I mean if that isn’t too much effort I’d be very grateful!
(the patch is based on the Dattorro Paper about Effect Design from 1997)

main gen-patcher: ai.genverb.gendsp (40.3 KB)
and the two absratactions I’m using: allpass-inv.gendsp (6.7 KB) & allpass.gendsp (6.8 KB)

Do you know how the faust2teensy would handle the delaytime interpolation? Right now I’m using parameters inside gen but the delay lines obviously need to be modulated in samplerate…

[zebra]

i see. well i would be very surprised if you couldn’t find a dattorro reverb in Faust by searching… but ok yes, that should be straightforward and why not, i can get to it sooner or later. (a nice 80’s modulated plate would be a good thing to have in the ol’ toolbox.)

@arev

how the faust2teensy would handle the delaytime interpolation

maybe i’m misunderstanding, but faust has many kinds of interpolated delays. (linear, nth-order lagrange, allpass.)
https://faust.grame.fr/doc/libraries/#basic-delay-functions
looks like the gen patch uses lin interp for predelay line.

sorry, probably did misunderstand. you mean these places where gen parameters control allpass tuning… that would be a job for fi.fdelay2a, plus whatever parameter smoothing is desired / feasible.

[arev]

I just wanted to report that I familiarised myself a little with FAUST (which I have to admit seems like an awesome platform, so thanks for getting me into that) and was able to implement the algorithm
I made a few additions here and there to build a “more” complete and useable effect but had to optimise its memory usage quite a bit afterwards, as the main goal was still being able to run the effect on the teensy. So for anybody who’s interested, take a look at it here.