#1

good question. let’s discuss.

2 Likes
#2

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

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!

4 Likes
#3

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!

#4

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?

1 Like
#5

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. :man_shrugging:

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…

4 Likes
#6

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.

#7

like i said above:

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.

#8

Alright thanks I’ll definitely give that a try :smiley:

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…

#9

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.)

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.

#10

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 :blush:
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.

3 Likes