faudiostream-users — List related to the usage of the FAUST language

Re: [Faudiostream-users] Hopefuly useful for some of you : JackMate — a native macOS companion for the Jack Audio server

[yann o. <or...@gm...>]

Very nice! Thanks for sharing, Eric.

Yann

Le lun. 13 avr. 2026 à 18:41, BAVU Eric <eri...@le...> a écrit :

>  Hi all,
>
> I use Faust for many years and always loved it (we use it for many tasks
> in our lab, both on Linux and macOS, and the most of time with faust2jaqt
> scripts).
>
> Faust targets many platforms and environments, so this will only be
> relevant to those of you working on macOS with Jack, but I thought it was
> worth sharing with the community.
>
> Over the past few months I developed JackMate, a native Swift/SwiftUI
> application to start, configure and patch the Jack Audio server on macOS.
>
> I always felt sad that JackPilot developed by sletz disappaeared from the
> ecosystem, and I even rewrote from scratch « JackCopilot » 5 years ago to
> revive it on our Apple devices in the lab.
>
> JackMate is a much larger project, completely rewritten in swift/swiftui
> for modern macOS (≥ 15 Sequoia) and ease of use for both advanced users and
> beginners in mind.
>
> For Faust users specifically, it works of course well alongside apps
> generated with faust2jaqt and faust2jack, and you can save complete
> sessions (Jack config + patchbay connections + CLI client commands with
> arguments) as named Studios and reload them in one click (I somewhat
> recreated the concept of Ladish studios used by the Cadence suite, but this
> time on macOS).
>
> If you’re interested, here is the website & documentation:
>
> https://zinc75.github.io/JackMate/
>
> You can inspect the source code of course (MIT License):
>
> https://github.com/zinc75/JackMate
>
> And you can install it easily with a DMG installer (Intel + Apple
> Silicon): https://github.com/zinc75/JackMate/releases/latest
>
> The app has been tested on Intel Macbook Pro on Sequoia, Mac Studio M1 Max
> on Tahoe, and even on a macbook Neo on Tahoe (surprised to see it worked on
> an iphone processor, which appears to be more powerful than my old 2019
> Intel Macbook Pro …)
>
> I would be happy to hear any feedback from you and don’t hesitate to post
> issues on Github if you find any !
>
> ------------------------------
>
>
> *Page personnelle* <https://acoustique.cnam.fr/contacts/bavu/> Éric Bavu
> Professeur des Universités - Acoustique
> *Laboratoire de Mécanique des Structures et des Systèmes Couplés *
> <https://www.lmssc.cnam.fr>
> 01.40.27.21.66 06.67.12.47.94 Bureau 31.0E.02, 2 rue Conté, 75003, Paris
> ------------------------------
>
>
> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>

[Faudiostream-users] Hopefuly useful for some of you : JackMate — a native macOS companion for the Jack Audio server

[BAVU E. <eri...@le...>]

 Hi all,

I use Faust for many years and always loved it (we use it for many tasks in our lab, both on Linux and macOS, and the most of time with faust2jaqt scripts).

Faust targets many platforms and environments, so this will only be relevant to those of you working on macOS with Jack, but I thought it was worth sharing with the community.

Over the past few months I developed JackMate, a native Swift/SwiftUI application to start, configure and patch the Jack Audio server on macOS.

I always felt sad that JackPilot developed by sletz disappaeared from the ecosystem, and I even rewrote from scratch « JackCopilot » 5 years ago to revive it on our Apple devices in the lab.

JackMate is a much larger project, completely rewritten in swift/swiftui for modern macOS (≥ 15 Sequoia) and ease of use for both advanced users and beginners in mind.

For Faust users specifically, it works of course well alongside apps generated with faust2jaqt and faust2jack, and you can save complete sessions (Jack config + patchbay connections + CLI client commands with arguments) as named Studios and reload them in one click (I somewhat recreated the concept of Ladish studios used by the Cadence suite, but this time on macOS).

If you’re interested, here is the website & documentation:

https://zinc75.github.io/JackMate/

You can inspect the source code of course (MIT License):

https://github.com/zinc75/JackMate

And you can install it easily with a DMG installer (Intel + Apple Silicon): https://github.com/zinc75/JackMate/releases/latest

The app has been tested on Intel Macbook Pro on Sequoia, Mac Studio M1 Max on Tahoe, and even on a macbook Neo on Tahoe (surprised to see it worked on an iphone processor, which appears to be more powerful than my old 2019 Intel Macbook Pro …)

I would be happy to hear any feedback from you and don’t hesitate to post issues on Github if you find any !

________________________________
[https://acoustique.cnam.fr/contacts/bavu/img/logo_cnam_losange.png]

Page personnelle<https://acoustique.cnam.fr/contacts/bavu/>     Éric Bavu
Professeur des Universités - Acoustique
Laboratoire de Mécanique des Structures et des Systèmes Couplés <https://www.lmssc.cnam.fr>
[https://s1g.s3.amazonaws.com/663d26351c15939abce2c2e80dc0bb46.png]     01.40.27.21.66  [https://s1g.s3.amazonaws.com/dc2614a30324c072f0887a285e5fe7c5.png]     06.67.12.47.94
Bureau 31.0E.02, 2 rue Conté, 75003, Paris
________________________________

[Faudiostream-users] Fwd: [grame-cncm/faust] Release 2.85.5 - Faust version 2.85.5

[Stéphane L. <le...@gr...>]

> Début du message réexpédié :
> 
> De: "github-actions[bot]" <not...@gi...>
> Objet: [grame-cncm/faust] Release 2.85.5 - Faust version 2.85.5
> Date: 20 mars 2026 à 18:49:14 UTC+1
> À: grame-cncm/faust <fa...@no...>
> Cc: Subscribed <sub...@no...>
> Répondre à: grame-cncm/faust <no...@gi...>
> 
> 
> Faust version 2.85.5 <https://github.com/grame-cncm/faust/releases/tag/2.85.5>
> Repository: grame-cncm/faust <https://github.com/grame-cncm/faust> · Tag: 2.85.5 <https://github.com/grame-cncm/faust/tree/2.85.5> · Commit: 3db77f5 <https://github.com/grame-cncm/faust/commit/3db77f58068918187f5ca7343e7f4ce269b62571> · Released by: github-actions[bot] <https://github.com/apps/github-actions>
> Change log
> 
> WARNING: to get the source version
> 
> be sure to download the faust-2.85.5.tar.gz file to get a complete source folder (in particular, with all the libraries).
> on macOS, binary files are still to notarise, you may have to use the xattr -rd com.apple.quarantine file command to remove the com.apple.quarantine extended attribute. See the xattr man page <https://developer.apple.com/documentation/os/reading_unix_manual_pages> for details on how to use that tool. MacOS Monterey is now the minimal version.
> New
> 
> Implement -it option in Rust backend.
> Improvements in faust2daisy.
> Add AssemblyScript backend.
> Add nam_faust_dsp.h and nam-jack-gtk.cpp to wrap and use NeuralAmpModelerCore code.
> Add compilation statistics in FIR backend.
> Add dsp_factory::getJSON method.
> Extended pattern matching for route.
> Add Claude generated brightOrgan.
> Add delay-line options and -scalar mode to faustbench-llvm.
> Improve rust codegen for wasm target.
> Update juce-midi.h for recent Juce compatibility.
> Deprecated
> 
> Fixed bugs
> 
> Various fixes in Rust backed.
> Incorrect cast of bargraph in FIR generation.
> Correct SR generation in subcontainers. Add subcontainer1 test and clang-tidy and ASan based tests.
> Renaming min_i/max_i in faustmini/faustmaxi in C and ocpp backends.
> Correct -single option in faustbench.
> Libraries
> 
> Add bitonic sorter functions, returning the sorted values or the indices of the sorted values.
> Add klonCentaur effect.
> Add WDF capacitor_Iout and inductor_Iout
> Add rpm.sawtooth oscillator.
> Add ef.doppler_shift pitch shifter.
> New TwinOsc oscillator.
> New hysteresis.lib.
> New debug.lib library.
> —
> This release has 11 assets:
> 
> Faust-2.85.5-arm64.dmg
> Faust-2.85.5-win64.exe
> Faust-2.85.5-x64.dmg
> faust-2.85.5.tar.gz
> faustgen-1.81-arm64.dmg
> faustgen-1.81-win64.zip
> faustgen-1.81-x64.dmg
> libfaust-ubuntu-aarch64.zip
> libfaust-ubuntu-x86_64.zip
> Source code (zip)
> Source code (tar.gz)
> Visit the release page <https://github.com/grame-cncm/faust/releases/tag/2.85.5> to download them.
> 
> —
> You are receiving this because you are watching this repository.
> View it on GitHub <https://github.com/grame-cncm/faust/releases/tag/2.85.5?email_source=notifications&email_token=AAK5HV7XY2QS5AJO35MTMUL4RWABVA5CNFSL6Z3JMQ5C6L3HNF2C22DVMIXVEZLMMVQXGZJPGI4TSNBYGIYTQONGOJSWC43PN2VHG5LCONRXE2LCMVSKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM> or unsubscribe <https://github.com/grame-cncm/faust/unsubscribe_via_email/AAK5HV5I5ZXLL4KRN2O6A5T4RWABVANCNFSM4BCYYZ3Q> from all notifications for this repository.
> 

Re: [Faudiostream-users] Introducing AI FX Builder

[Stéphane L. <le...@gr...>]

Hi Robin,

The  Faust compiler is LGPL.

Stéphane 

> Le 17 mars 2026 à 23:50, Robin Gareus <ro...@ga...> a écrit :
> 
> Last month at the Berlin Developer Meetup there was a presentation of
> 
> https://www.pluginmaker.ai/ which also uses FAUST under the hood.
> 
> and in January there was another project presented that showcased speech to plugin, also using FAUST as indirection for real-time safety and proper DSP. But given that LLM generated code cannot be (C)ed it was never released to the public.
> 
> Do you know how chaosaudio.com deals with using GPL'ed FAUST code?
> 
> --
> robin
> 
> 
> On 2026-03-17 10:46 PM, Stéphane Letz wrote:
>> Powered by Faust: https://chaosaudio.com/blogs/whats-new/introducing-ai-fx-builder-create-any-effect-you-can-imagine
>> Stéphane
>> _______________________________________________
>> Faudiostream-users mailing list
>> Fau...@li...
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> 
> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Introducing AI FX Builder

[Robin G. <ro...@ga...>]

Last month at the Berlin Developer Meetup there was a presentation of

https://www.pluginmaker.ai/ which also uses FAUST under the hood.

and in January there was another project presented that showcased speech 
to plugin, also using FAUST as indirection for real-time safety and 
proper DSP. But given that LLM generated code cannot be (C)ed it was 
never released to the public.

Do you know how chaosaudio.com deals with using GPL'ed FAUST code?

--
robin


On 2026-03-17 10:46 PM, Stéphane Letz wrote:
> Powered by Faust: https://chaosaudio.com/blogs/whats-new/introducing-ai-fx-builder-create-any-effect-you-can-imagine
> 
> Stéphane
> 
> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Introducing AI FX Builder

[Stéphane L. <le...@gr...>]

Powered by Faust: https://chaosaudio.com/blogs/whats-new/introducing-ai-fx-builder-create-any-effect-you-can-imagine

Stéphane 

Re: [Faudiostream-users] Question about creating a triangle wave

[Aaron K. J. <akj...@gm...>]

Not sure if it would make a difference to how UI elements use more or less
RAM, etc. but OSC and MIDI messages in Faust are strongly-coupled to the
*slider elements. It's convenient, but makes me wonder 2 things:

1) if you shouldn't try to see what happens not using a GUI, i.e.
declare the UI elements, but compile using something like
`faust2jackconsole`, which is all about using pure OSC and MIDI messages
without a GUI.
2) if `faust` couldn't use a more low-level primitive set of MIDI functions
not so strongly-tied to sliders?

As mentioned, the other thing to do would be to simply compile your Faust
to C (not C++) and do some manual light-weight cut-n-paste into your
project using libraries that don't create a lot of overhead. Faust is
great, but the choice of C++, much heavier than C, as a default, isn't the
greatest, necessarily. Luckily, there's a way to make Faust compile to C,
and I've used it before to excellent effect when the situation calls for it.


Aaron Krister Johnson
Music, etc.:
https://soundcloud.com/aaron-krister-johnson
https://soundcloud.com/filtercreed
https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg
https://aaronkristerjohnson.bandcamp.com/
http://www.untwelve.org
Code:
https://github.com/akjmicro <http://www.untwelve.org>


On Sun, Mar 8, 2026 at 10:35 AM Tejas Rode <tej...@gm...> wrote:

> Thanks Tommy! No, I haven’t tried creating triangles in parallel,
> primarily because all of them are supposed to have different frequencies
> and other parameters.
>
> Last night, I tried to use Claude to create a .h file in teensy for an
> alias suppressed triangle whose frequency, duty cycle, phase and amplitude
> can be set in the teensy loop. Claude did it!
>
> The reason I was using faust was that the language is more intuitive as
> compared to doing the same from scratch in teensy. With tools like Claude,
> that’s no more a barrier. For now, I’ve paused my efforts in faust.
>
> Thanks,
> Tejas
>
>
> On Sun, Mar 8, 2026 at 8:22 AM Tommy Rushton <tom...@gm...>
> wrote:
>
>> My Faust program contains 30+ UI elements; I'm not creating 30+ instances
>> of my Faust program. Now that I think about it, instead of
>>
>> FaustTriangle faustTriangle[4];
>>
>> have you tried creating your triangles in parallel in Faust? I.e.
>> something like
>>
>> process = par(i, 4, trinangleND(N, hslider("freq%i", ...), hslider("duty%i", ...), hslider("phase%i", ...)));
>>
>> Tommy
>> Le 06/03/2026 à 18:44, Tejas Rode a écrit :
>>
>> Thank you Tommy!
>>
>> Does your teensy use 30+ instances of ONE faust object? Have you tried
>> that? That’s where I’m stuck.
>>
>> My teensy doesn’t have the extra PSRAM, so I’ll have to work with the
>> default. Also, I’m not yet doing si.smoo, but will avoid that. I don’t
>> think there are large arrays. You can take a look at my faust code from
>> this email thread.
>>
>> Thanks,
>> Tejas
>>
>>
>> On Fri, Mar 6, 2026 at 8:36 AM Tommy Rushton <tom...@gm...>
>> wrote:
>>
>>> Hi Tejas,
>>>
>>> The faust2[...] tools accept any valid Faust flags as additional
>>> arguments. What I can tell you is, per the script excerpt I shared last
>>> time, faust2teensy does indeed employ the -uim flag implicitly by default
>>> (i.e. specifying it explicitly would be redundant). To answer your
>>> question, yes when you click the truck icon, select teensy as your Platform
>>> and cilck *Compile*, faust2teensy is executed and your code benefits
>>> from application of the -uim flag.
>>>
>>> I've been following this discussion with some curiosity because I work
>>> with the Teensy and have a Faust algorithm with 30+ UI elements that runs
>>> fine. Where I run into problems is with delay lines (due to memory
>>> limitations posed by the Teensy — though experimenting with adding extra
>>> PSRAM has shown promise) and parameter smoothing (I avoid si.smoo and do my
>>> smoothing *outside* of Faust). Does your generated C++ code exhibit any
>>> large arrays? If so, have you experimented with the -dlt flag?
>>>
>>> Cheers,
>>>
>>> Tommy
>>> Le 06/03/2026 à 13:30, Tejas Rode a écrit :
>>>
>>> The documentation on faust for teensy
>>> https://faustdoc.grame.fr/tutorials/teensy/ states that the command run
>>> with the truck icon is:
>>>
>>> faust2teensy -lib FaustTriangle.dsp
>>>
>>> The git
>>> https://github.com/grame-cncm/faust/tree/master-dev/architecture/teensy
>>> doesn't mention -uim as an available option for faust2teensy, though it is
>>> available for faust in general https://faustdoc.grame.fr/manual/options/
>>>
>>> This means that more than 3 instances are really not possible with the
>>> current state of faust2teensy.
>>>
>>> Thank you all for helping with this!
>>> Tejas
>>>
>>> On Thu, Mar 5, 2026 at 2:24 PM Tejas Rode <tej...@gm...> wrote:
>>>
>>> Great conversation and inputs!
>>>>
>>>> Tommy, is the -uim flag implicitly used when I click on the 'truck'
>>>> icon and select 'teensy' in fausteditor online? If not, how could I enable
>>>> it? Since I'm new to faust, I'll need some direction there.
>>>>
>>>> If, in the end, the upper limit on the number of instances of
>>>> alias-suppressed triangle acts as a roadblock, I'll have to unfortunately
>>>> move away from faust, and rely on what native teensy functions can do.
>>>>
>>>> Thanks,
>>>> Tejas
>>>>
>>>> On Thu, Mar 5, 2026 at 10:22 AM Tommy Rushton <tom...@gm...>
>>>> wrote:
>>>>
>>> The -uim option already generates lightweight C macros as an
>>>>> alternative, but no embedded architecture currently uses it.
>>>>>
>>>>> On the contrary, faust2teensy uses this flag...
>>>>>
>>>>> if [ $LIB -eq 1 ]; then    mkdir -p $MODULENAME
>>>>>     faust $OPTIONS -uim -a $FAUSTARCH/teensy/teensy.cpp -i $FILE -o $MODULENAME/$MODULENAME.cpp
>>>>>
>>>>> etc.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Tommy
>>>>>
>>>>>
>>>>> Le 05/03/2026 à 16:28, Julius Smith a écrit :
>>>>>
>>>> > Can Gemini help ((-: ?
>>>>>
>>>>> Absolutely!  However, for software development, I prefer Claude Opus
>>>>> 4.6 (with "thinking" enabled liberally).  Here is Claude's first take:
>>>>>
>>>>> Prompt:
>>>>> > Research existing Faust architecture files for embedded targets to
>>>>> understand what currently exists
>>>>>
>>>>> Reply:
>>>>> Here is an overview of existing Faust architecture files for embedded
>>>>> platforms, compiled by browsing the Faust GitHub repo and documentation
>>>>> site.
>>>>>
>>>>> OVERVIEW OF EXISTING FAUST ARCHITECTURE FILES FOR EMBEDDED PROCESSORS
>>>>> =====================================================================
>>>>>
>>>>> THE CURRENT LANDSCAPE
>>>>>
>>>>> Faust currently targets seven embedded/microcontroller platforms
>>>>> through dedicated architecture files and faust2xx scripts. Each has its own
>>>>> directory under architecture/ in the Faust repo, plus a corresponding
>>>>> faust2xx script in tools/faust2appls/. Here is what exists:
>>>>>
>>>>>
>>>>> 1. TEENSY (architecture/teensy/)
>>>>>
>>>>> Files: teensy.cpp, teensy.h, README
>>>>> Last updated: Nov 2023 (3 years ago)
>>>>> Script: faust2teensy [-lib] [-midi] [-nvoices <num>]
>>>>>
>>>>> Generates objects compatible with the PJRC Teensy Audio Library. The
>>>>> generated C++ class derives from AudioStream and uses setParamValue with
>>>>> string-matching metadata tables to expose hslider/nentry/vslider controls.
>>>>> Supports Teensy 3.6 and 4.x (FPU required). Has a tutorial on the Faust
>>>>> documentation site. Key limitations (as exposed in this email thread): the
>>>>> UI metadata/control structure (string-matching table for setParamValue)
>>>>> creates substantial overhead, limiting the number of instances that can run
>>>>> concurrently. No -mem or -sdram option support.
>>>>>
>>>>>
>>>>> 2. DAISY (architecture/daisy/)
>>>>>
>>>>> Files: ex_faust.cpp, Makefile, faust_daisy_mem.py, README
>>>>> Last updated: Dec 2025 (3 months ago, actively maintained)
>>>>> Script: faust2daisy [-patch] [-pod] [-patchsm] [-sdram] [-mem-thresh
>>>>> <num>] [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>] [-sram] [-qspi]
>>>>>
>>>>> Supports Electrosmith Daisy Seed, Pod, Patch, and Patch.Init() boards.
>>>>> Has the most sophisticated embedded memory handling: a Python script
>>>>> (faust_daisy_mem.py) post-processes generated C++ to move large buffers to
>>>>> SDRAM. Supports multiple flash modes (FLASH, SRAM, QSPI). Uses custom
>>>>> DaisyControlUI.h and daisy-midi.h headers. The README notes an active
>>>>> refactoring underway, with planned features including more compact code,
>>>>> static memory allocation, and MIDI polyphonic support. No tutorial on the
>>>>> Faust documentation site.
>>>>>
>>>>>
>>>>> 3. ESP32 (architecture/esp32/)
>>>>>
>>>>> Re. the latter, since si.smoo works on a per-sample basis it's way too
>>>>> heavy for the Teensy's CPU (picture trying to smooth the XY-coordinates of
>>>>> 16 virtual sound sources), so I take a hybrid approach and do my parameter
>>>>> smoothing outside of Faust
>>>>>
>>>>> Script: faust2esp32 [-lib] [-gramophone] [-multi] [-midi] [-nvoices
>>>>> <num>] [-wm8978 or -ac101]
>>>>>
>>>>> Targets the Espressif ESP32 family. Generates a C++ class and audio
>>>>> codec configuration objects. Currently supports the Wolfson WM8978 (TTGO
>>>>> T-Audio) and AC101 codecs. Has a dedicated GRAME "Gramophone" mode. Has a
>>>>> tutorial on the Faust documentation site. Includes a drivers/ folder with
>>>>> codec-specific documentation.
>>>>>
>>>>>
>>>>> 4. HOTHOUSE (architecture/hothouse/)
>>>>>
>>>>> Script: faust2hothouse [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>]
>>>>>
>>>>> Targets the Cleveland Music Co. Hothouse DIY Pedal (Daisy-based).
>>>>> Supports 6 knobs, 3 toggle switches, and 2 foot switches via [knob:N],
>>>>> [toggle:N], [foot:N] metadata. Uses a Python script for SDRAM placement of
>>>>> large buffers (same approach as Daisy). Uses custom HothouseControlUI.h and
>>>>> shares daisy-midi.h with the Daisy architecture. Relatively recent addition.
>>>>>
>>>>>
>>>>> 5. BELA (architecture/bela.cpp)
>>>>>
>>>>> Script: faust2bela
>>>>>
>>>>> A single architecture file for the Bela platform (BeagleBone
>>>>> Black-based). Bela is more of an embedded Linux system than a bare-metal
>>>>> microcontroller, so it has more resources available. Architecture file was
>>>>> last touched in April 2024.
>>>>>
>>>>>
>>>>> 6. OWL (architecture/owl.cpp)
>>>>>
>>>>> Script: faust2owl
>>>>>
>>>>> Targets the Rebel Technology OWL platform. Notable because it already
>>>>> implements a custom OwlMemoryManager (using the Faust -mem memory manager
>>>>> API), making it one of the few embedded architectures that leverages the
>>>>> custom memory allocation infrastructure. Single file architecture.
>>>>>
>>>>>
>>>>> 7. CHAOS STRATUS (architecture/chaos-stratus/)
>>>>>
>>>>> Script: faust2stratus
>>>>>
>>>>> Targets the Chaos Audio Stratus guitar pedal. Uses a Linux-based
>>>>> embedded system with SSH/SCP deployment. Architecture includes build
>>>>> scripts, Docker support for cross-compilation, and a stratus.cpp file.
>>>>> Relatively sophisticated deployment pipeline.
>>>>>
>>>>>
>>>>> 8. SAM (architecture/sam/)
>>>>>
>>>>> An older, apparently less-maintained architecture (last commit from
>>>>> 2019).
>>>>>
>>>>>
>>>>> CROSS-CUTTING INFRASTRUCTURE ALREADY AVAILABLE
>>>>> ===============================================
>>>>>
>>>>> The Faust compiler already provides several features that are relevant
>>>>> to embedded targets but are NOT uniformly exploited across all embedded
>>>>> architectures:
>>>>>
>>>>> The -mem / --memory-manager option: Generates code where large arrays
>>>>> become pointers allocated via an external dsp_memory_manager. This enables
>>>>> distributing DSP memory across SRAM/SDRAM/DTCM. The memoryInfo() method
>>>>> provides detailed information about each zone's size and read/write access
>>>>> patterns. Currently only the OWL architecture actually uses this. The Daisy
>>>>> architecture works around the same problem with a Python post-processing
>>>>> script instead.
>>>>>
>>>>> The -uim option: Generates static C preprocessor macros
>>>>> (FAUST_ADDHORIZONTALSLIDER, FAUST_LIST_ACTIVES, etc.) that describe control
>>>>> parameters without requiring the full UI class hierarchy. This is ideal for
>>>>> embedded platforms where you don't need a graphical UI and want to avoid
>>>>> the overhead of buildUserInterface and its metadata tables. Demonstrated in
>>>>> minimal-static.cpp but not used by any current embedded architecture.
>>>>>
>>>>> The -inpl (in-place) option: Generates code where input and output
>>>>> buffers can be the same memory -- noted in the docs as being "typically
>>>>> needed in some embedded devices." Only works in scalar mode.
>>>>>
>>>>> The C backend (-lang c): Can generate pure C code instead of C++,
>>>>> avoiding C++ runtime overhead (vtables, exceptions, RTTI, stdio, etc.).
>>>>> Uses CGlue.h and CInterface.h. Not currently used by any embedded
>>>>> architecture.
>>>>>
>>>>> Metadata conventions: A common set of [switch:N], [knob:N] metadata
>>>>> has been defined for devices without screens. The Hothouse extends this
>>>>> with [toggle:N] and [foot:N]. The documentation notes that this set "will
>>>>> probably have to be progressively defined and standardized."
>>>>>
>>>>> JSON memory layout: When using -mem -json, the complete memory layout
>>>>> is emitted in JSON, allowing compile-time memory planning (e.g., using
>>>>> #pragma directives for memory segments). This enables hybrid static/dynamic
>>>>> memory management.
>>>>>
>>>>>
>>>>> GAPS AND OPPORTUNITIES (What Stephane Is Calling For)
>>>>> =====================================================
>>>>>
>>>>> Based on this survey, the key gaps that new "embedded hardware aware"
>>>>> architecture files could address:
>>>>>
>>>>> UI overhead problem: The Teensy thread exposed this directly -- the
>>>>> standard buildUserInterface / setParamValue / string-matching metadata
>>>>> table approach creates significant memory and code overhead. The -uim
>>>>> option already generates lightweight C macros as an alternative, but no
>>>>> embedded architecture currently uses it.
>>>>>
>>>>> No uniform memory management: Each platform handles memory constraints
>>>>> differently -- Daisy uses a Python post-processor, OWL uses -mem with a
>>>>> custom allocator, Teensy has no solution at all. A unified approach using
>>>>> -mem with platform-specific allocators would be cleaner.
>>>>>
>>>>> C++ library bloat: As Stephane noted, even using stdio can produce
>>>>> huge binaries. The C backend (-lang c) could help, but there are no
>>>>> architecture files that use it for embedded targets. Raw C output combined
>>>>> with -uim macros could produce dramatically smaller binaries.
>>>>>
>>>>> Inconsistent feature support: The Daisy architecture is the most
>>>>> complete (SDRAM support, multiple board variants, flash modes, active
>>>>> refactoring), while Teensy hasn't been touched in over 3 years. No embedded
>>>>> architecture supports the -mem option uniformly.
>>>>>
>>>>> No Pico DSP architecture: Despite being mentioned in the Faust
>>>>> documentation's embedded platforms section, there is no faust2pico or Pico
>>>>> architecture directory.
>>>>>
>>>>> Limited documentation: Only Teensy and ESP32 have tutorials on the
>>>>> Faust documentation site. No Daisy tutorial exists despite it being the
>>>>> most actively developed embedded target.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Faudiostream-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>>>
>>>>> _______________________________________________
>>>>> Faudiostream-users mailing list
>>>>> Fau...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>>>
>>>> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>

Re: [Faudiostream-users] mesh2faust on macos

[Henrik F. <fr...@gm...>]

Sure!

Den mån 9 mars 2026 kl 11:30 skrev Stéphane Letz <le...@gr...>:

> Hi Henrik,
>
> Better open an issue on https://github.com/grame-cncm/faust/issues and
> ping  @khiner  who is maintaining this mesh2faust tool.
>
> Stéphane
>
> > Le 9 mars 2026 à 11:18, Henrik Frisk <fr...@gm...> a écrit :
> >
> > Hi,
> >
> > I'm trying to compile mesh2faust on macos but I'm getting the following
> error:
> >
> > mesh2faust.cpp:11:10: fatal error: 'Spectra/MatOp/SparseSymMatProd.h'
> file not found
> >
> > It appears to have to do with eigen which I have installed with brew
> install eigen but I'm guessing some path is not set properly. Setting
> PKG_CONFIG_PATH to the relevant does not seem to help.
> >
> > Any suggestions?
> >
> > /Henrik
> > _______________________________________________
> > Faudiostream-users mailing list
> > Fau...@li...
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>

Re: [Faudiostream-users] mesh2faust on macos

[Stéphane L. <le...@gr...>]

Hi Henrik,

Better open an issue on https://github.com/grame-cncm/faust/issues and ping  @khiner  who is maintaining this mesh2faust tool.

Stéphane 

> Le 9 mars 2026 à 11:18, Henrik Frisk <fr...@gm...> a écrit :
> 
> Hi,
> 
> I'm trying to compile mesh2faust on macos but I'm getting the following error:
> 
> mesh2faust.cpp:11:10: fatal error: 'Spectra/MatOp/SparseSymMatProd.h' file not found
> 
> It appears to have to do with eigen which I have installed with brew install eigen but I'm guessing some path is not set properly. Setting PKG_CONFIG_PATH to the relevant does not seem to help.
> 
> Any suggestions?
> 
> /Henrik
> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] mesh2faust on macos

[Henrik F. <fr...@gm...>]

Hi,

I'm trying to compile mesh2faust on macos but I'm getting the following
error:

mesh2faust.cpp:11:10: fatal error: 'Spectra/MatOp/SparseSymMatProd.h' file
not found

It appears to have to do with eigen which I have installed with brew
install eigen but I'm guessing some path is not set properly.
Setting PKG_CONFIG_PATH to the relevant does not seem to help.

Any suggestions?

/Henrik

Re: [Faudiostream-users] Question about creating a triangle wave

[Tejas R. <tej...@gm...>]

Thanks Tommy! No, I haven’t tried creating triangles in parallel, primarily
because all of them are supposed to have different frequencies and other
parameters.

Last night, I tried to use Claude to create a .h file in teensy for an
alias suppressed triangle whose frequency, duty cycle, phase and amplitude
can be set in the teensy loop. Claude did it!

The reason I was using faust was that the language is more intuitive as
compared to doing the same from scratch in teensy. With tools like Claude,
that’s no more a barrier. For now, I’ve paused my efforts in faust.

Thanks,
Tejas


On Sun, Mar 8, 2026 at 8:22 AM Tommy Rushton <tom...@gm...>
wrote:

> My Faust program contains 30+ UI elements; I'm not creating 30+ instances
> of my Faust program. Now that I think about it, instead of
>
> FaustTriangle faustTriangle[4];
>
> have you tried creating your triangles in parallel in Faust? I.e.
> something like
>
> process = par(i, 4, trinangleND(N, hslider("freq%i", ...), hslider("duty%i", ...), hslider("phase%i", ...)));
>
> Tommy
> Le 06/03/2026 à 18:44, Tejas Rode a écrit :
>
> Thank you Tommy!
>
> Does your teensy use 30+ instances of ONE faust object? Have you tried
> that? That’s where I’m stuck.
>
> My teensy doesn’t have the extra PSRAM, so I’ll have to work with the
> default. Also, I’m not yet doing si.smoo, but will avoid that. I don’t
> think there are large arrays. You can take a look at my faust code from
> this email thread.
>
> Thanks,
> Tejas
>
>
> On Fri, Mar 6, 2026 at 8:36 AM Tommy Rushton <tom...@gm...>
> wrote:
>
>> Hi Tejas,
>>
>> The faust2[...] tools accept any valid Faust flags as additional
>> arguments. What I can tell you is, per the script excerpt I shared last
>> time, faust2teensy does indeed employ the -uim flag implicitly by default
>> (i.e. specifying it explicitly would be redundant). To answer your
>> question, yes when you click the truck icon, select teensy as your Platform
>> and cilck *Compile*, faust2teensy is executed and your code benefits
>> from application of the -uim flag.
>>
>> I've been following this discussion with some curiosity because I work
>> with the Teensy and have a Faust algorithm with 30+ UI elements that runs
>> fine. Where I run into problems is with delay lines (due to memory
>> limitations posed by the Teensy — though experimenting with adding extra
>> PSRAM has shown promise) and parameter smoothing (I avoid si.smoo and do my
>> smoothing *outside* of Faust). Does your generated C++ code exhibit any
>> large arrays? If so, have you experimented with the -dlt flag?
>>
>> Cheers,
>>
>> Tommy
>> Le 06/03/2026 à 13:30, Tejas Rode a écrit :
>>
>> The documentation on faust for teensy
>> https://faustdoc.grame.fr/tutorials/teensy/ states that the command run
>> with the truck icon is:
>>
>> faust2teensy -lib FaustTriangle.dsp
>>
>> The git
>> https://github.com/grame-cncm/faust/tree/master-dev/architecture/teensy
>> doesn't mention -uim as an available option for faust2teensy, though it is
>> available for faust in general https://faustdoc.grame.fr/manual/options/
>>
>> This means that more than 3 instances are really not possible with the
>> current state of faust2teensy.
>>
>> Thank you all for helping with this!
>> Tejas
>>
>> On Thu, Mar 5, 2026 at 2:24 PM Tejas Rode <tej...@gm...> wrote:
>>
>> Great conversation and inputs!
>>>
>>> Tommy, is the -uim flag implicitly used when I click on the 'truck' icon
>>> and select 'teensy' in fausteditor online? If not, how could I enable it?
>>> Since I'm new to faust, I'll need some direction there.
>>>
>>> If, in the end, the upper limit on the number of instances of
>>> alias-suppressed triangle acts as a roadblock, I'll have to unfortunately
>>> move away from faust, and rely on what native teensy functions can do.
>>>
>>> Thanks,
>>> Tejas
>>>
>>> On Thu, Mar 5, 2026 at 10:22 AM Tommy Rushton <tom...@gm...>
>>> wrote:
>>>
>> The -uim option already generates lightweight C macros as an alternative,
>>>> but no embedded architecture currently uses it.
>>>>
>>>> On the contrary, faust2teensy uses this flag...
>>>>
>>>> if [ $LIB -eq 1 ]; then    mkdir -p $MODULENAME
>>>>     faust $OPTIONS -uim -a $FAUSTARCH/teensy/teensy.cpp -i $FILE -o $MODULENAME/$MODULENAME.cpp
>>>>
>>>> etc.
>>>>
>>>> Cheers,
>>>>
>>>> Tommy
>>>>
>>>>
>>>> Le 05/03/2026 à 16:28, Julius Smith a écrit :
>>>>
>>> > Can Gemini help ((-: ?
>>>>
>>>> Absolutely!  However, for software development, I prefer Claude Opus
>>>> 4.6 (with "thinking" enabled liberally).  Here is Claude's first take:
>>>>
>>>> Prompt:
>>>> > Research existing Faust architecture files for embedded targets to
>>>> understand what currently exists
>>>>
>>>> Reply:
>>>> Here is an overview of existing Faust architecture files for embedded
>>>> platforms, compiled by browsing the Faust GitHub repo and documentation
>>>> site.
>>>>
>>>> OVERVIEW OF EXISTING FAUST ARCHITECTURE FILES FOR EMBEDDED PROCESSORS
>>>> =====================================================================
>>>>
>>>> THE CURRENT LANDSCAPE
>>>>
>>>> Faust currently targets seven embedded/microcontroller platforms
>>>> through dedicated architecture files and faust2xx scripts. Each has its own
>>>> directory under architecture/ in the Faust repo, plus a corresponding
>>>> faust2xx script in tools/faust2appls/. Here is what exists:
>>>>
>>>>
>>>> 1. TEENSY (architecture/teensy/)
>>>>
>>>> Files: teensy.cpp, teensy.h, README
>>>> Last updated: Nov 2023 (3 years ago)
>>>> Script: faust2teensy [-lib] [-midi] [-nvoices <num>]
>>>>
>>>> Generates objects compatible with the PJRC Teensy Audio Library. The
>>>> generated C++ class derives from AudioStream and uses setParamValue with
>>>> string-matching metadata tables to expose hslider/nentry/vslider controls.
>>>> Supports Teensy 3.6 and 4.x (FPU required). Has a tutorial on the Faust
>>>> documentation site. Key limitations (as exposed in this email thread): the
>>>> UI metadata/control structure (string-matching table for setParamValue)
>>>> creates substantial overhead, limiting the number of instances that can run
>>>> concurrently. No -mem or -sdram option support.
>>>>
>>>>
>>>> 2. DAISY (architecture/daisy/)
>>>>
>>>> Files: ex_faust.cpp, Makefile, faust_daisy_mem.py, README
>>>> Last updated: Dec 2025 (3 months ago, actively maintained)
>>>> Script: faust2daisy [-patch] [-pod] [-patchsm] [-sdram] [-mem-thresh
>>>> <num>] [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>] [-sram] [-qspi]
>>>>
>>>> Supports Electrosmith Daisy Seed, Pod, Patch, and Patch.Init() boards.
>>>> Has the most sophisticated embedded memory handling: a Python script
>>>> (faust_daisy_mem.py) post-processes generated C++ to move large buffers to
>>>> SDRAM. Supports multiple flash modes (FLASH, SRAM, QSPI). Uses custom
>>>> DaisyControlUI.h and daisy-midi.h headers. The README notes an active
>>>> refactoring underway, with planned features including more compact code,
>>>> static memory allocation, and MIDI polyphonic support. No tutorial on the
>>>> Faust documentation site.
>>>>
>>>>
>>>> 3. ESP32 (architecture/esp32/)
>>>>
>>>> Re. the latter, since si.smoo works on a per-sample basis it's way too
>>>> heavy for the Teensy's CPU (picture trying to smooth the XY-coordinates of
>>>> 16 virtual sound sources), so I take a hybrid approach and do my parameter
>>>> smoothing outside of Faust
>>>>
>>>> Script: faust2esp32 [-lib] [-gramophone] [-multi] [-midi] [-nvoices
>>>> <num>] [-wm8978 or -ac101]
>>>>
>>>> Targets the Espressif ESP32 family. Generates a C++ class and audio
>>>> codec configuration objects. Currently supports the Wolfson WM8978 (TTGO
>>>> T-Audio) and AC101 codecs. Has a dedicated GRAME "Gramophone" mode. Has a
>>>> tutorial on the Faust documentation site. Includes a drivers/ folder with
>>>> codec-specific documentation.
>>>>
>>>>
>>>> 4. HOTHOUSE (architecture/hothouse/)
>>>>
>>>> Script: faust2hothouse [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>]
>>>>
>>>> Targets the Cleveland Music Co. Hothouse DIY Pedal (Daisy-based).
>>>> Supports 6 knobs, 3 toggle switches, and 2 foot switches via [knob:N],
>>>> [toggle:N], [foot:N] metadata. Uses a Python script for SDRAM placement of
>>>> large buffers (same approach as Daisy). Uses custom HothouseControlUI.h and
>>>> shares daisy-midi.h with the Daisy architecture. Relatively recent addition.
>>>>
>>>>
>>>> 5. BELA (architecture/bela.cpp)
>>>>
>>>> Script: faust2bela
>>>>
>>>> A single architecture file for the Bela platform (BeagleBone
>>>> Black-based). Bela is more of an embedded Linux system than a bare-metal
>>>> microcontroller, so it has more resources available. Architecture file was
>>>> last touched in April 2024.
>>>>
>>>>
>>>> 6. OWL (architecture/owl.cpp)
>>>>
>>>> Script: faust2owl
>>>>
>>>> Targets the Rebel Technology OWL platform. Notable because it already
>>>> implements a custom OwlMemoryManager (using the Faust -mem memory manager
>>>> API), making it one of the few embedded architectures that leverages the
>>>> custom memory allocation infrastructure. Single file architecture.
>>>>
>>>>
>>>> 7. CHAOS STRATUS (architecture/chaos-stratus/)
>>>>
>>>> Script: faust2stratus
>>>>
>>>> Targets the Chaos Audio Stratus guitar pedal. Uses a Linux-based
>>>> embedded system with SSH/SCP deployment. Architecture includes build
>>>> scripts, Docker support for cross-compilation, and a stratus.cpp file.
>>>> Relatively sophisticated deployment pipeline.
>>>>
>>>>
>>>> 8. SAM (architecture/sam/)
>>>>
>>>> An older, apparently less-maintained architecture (last commit from
>>>> 2019).
>>>>
>>>>
>>>> CROSS-CUTTING INFRASTRUCTURE ALREADY AVAILABLE
>>>> ===============================================
>>>>
>>>> The Faust compiler already provides several features that are relevant
>>>> to embedded targets but are NOT uniformly exploited across all embedded
>>>> architectures:
>>>>
>>>> The -mem / --memory-manager option: Generates code where large arrays
>>>> become pointers allocated via an external dsp_memory_manager. This enables
>>>> distributing DSP memory across SRAM/SDRAM/DTCM. The memoryInfo() method
>>>> provides detailed information about each zone's size and read/write access
>>>> patterns. Currently only the OWL architecture actually uses this. The Daisy
>>>> architecture works around the same problem with a Python post-processing
>>>> script instead.
>>>>
>>>> The -uim option: Generates static C preprocessor macros
>>>> (FAUST_ADDHORIZONTALSLIDER, FAUST_LIST_ACTIVES, etc.) that describe control
>>>> parameters without requiring the full UI class hierarchy. This is ideal for
>>>> embedded platforms where you don't need a graphical UI and want to avoid
>>>> the overhead of buildUserInterface and its metadata tables. Demonstrated in
>>>> minimal-static.cpp but not used by any current embedded architecture.
>>>>
>>>> The -inpl (in-place) option: Generates code where input and output
>>>> buffers can be the same memory -- noted in the docs as being "typically
>>>> needed in some embedded devices." Only works in scalar mode.
>>>>
>>>> The C backend (-lang c): Can generate pure C code instead of C++,
>>>> avoiding C++ runtime overhead (vtables, exceptions, RTTI, stdio, etc.).
>>>> Uses CGlue.h and CInterface.h. Not currently used by any embedded
>>>> architecture.
>>>>
>>>> Metadata conventions: A common set of [switch:N], [knob:N] metadata has
>>>> been defined for devices without screens. The Hothouse extends this with
>>>> [toggle:N] and [foot:N]. The documentation notes that this set "will
>>>> probably have to be progressively defined and standardized."
>>>>
>>>> JSON memory layout: When using -mem -json, the complete memory layout
>>>> is emitted in JSON, allowing compile-time memory planning (e.g., using
>>>> #pragma directives for memory segments). This enables hybrid static/dynamic
>>>> memory management.
>>>>
>>>>
>>>> GAPS AND OPPORTUNITIES (What Stephane Is Calling For)
>>>> =====================================================
>>>>
>>>> Based on this survey, the key gaps that new "embedded hardware aware"
>>>> architecture files could address:
>>>>
>>>> UI overhead problem: The Teensy thread exposed this directly -- the
>>>> standard buildUserInterface / setParamValue / string-matching metadata
>>>> table approach creates significant memory and code overhead. The -uim
>>>> option already generates lightweight C macros as an alternative, but no
>>>> embedded architecture currently uses it.
>>>>
>>>> No uniform memory management: Each platform handles memory constraints
>>>> differently -- Daisy uses a Python post-processor, OWL uses -mem with a
>>>> custom allocator, Teensy has no solution at all. A unified approach using
>>>> -mem with platform-specific allocators would be cleaner.
>>>>
>>>> C++ library bloat: As Stephane noted, even using stdio can produce huge
>>>> binaries. The C backend (-lang c) could help, but there are no architecture
>>>> files that use it for embedded targets. Raw C output combined with -uim
>>>> macros could produce dramatically smaller binaries.
>>>>
>>>> Inconsistent feature support: The Daisy architecture is the most
>>>> complete (SDRAM support, multiple board variants, flash modes, active
>>>> refactoring), while Teensy hasn't been touched in over 3 years. No embedded
>>>> architecture supports the -mem option uniformly.
>>>>
>>>> No Pico DSP architecture: Despite being mentioned in the Faust
>>>> documentation's embedded platforms section, there is no faust2pico or Pico
>>>> architecture directory.
>>>>
>>>> Limited documentation: Only Teensy and ESP32 have tutorials on the
>>>> Faust documentation site. No Daisy tutorial exists despite it being the
>>>> most actively developed embedded target.
>>>>
>>>>
>>>> _______________________________________________
>>>> Faudiostream-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>>
>>>> _______________________________________________
>>>> Faudiostream-users mailing list
>>>> Fau...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>>
>>>

Re: [Faudiostream-users] Question about creating a triangle wave

[Tommy R. <tom...@gm...>]

My Faust program contains 30+ UI elements; I'm not creating 30+ 
instances of my Faust program. Now that I think about it, instead of

FaustTriangle faustTriangle[4];

have you tried creating your triangles in parallel in Faust? I.e. 
something like

process = par(i, 4, trinangleND(N, hslider("freq%i", ...), hslider("duty%i", ...), hslider("phase%i", ...)));

Tommy

Le 06/03/2026 à 18:44, Tejas Rode a écrit :
> Thank you Tommy!
>
> Does your teensy use 30+ instances of ONE faust object? Have you tried 
> that? That’s where I’m stuck.
>
> My teensy doesn’t have the extra PSRAM, so I’ll have to work with the 
> default. Also, I’m not yet doing si.smoo, but will avoid that. I don’t 
> think there are large arrays. You can take a look at my faust code 
> from this email thread.
>
> Thanks,
> Tejas
>
>
> On Fri, Mar 6, 2026 at 8:36 AM Tommy Rushton <tom...@gm...> 
> wrote:
>
>     Hi Tejas,
>
>     The faust2[...] tools accept any valid Faust flags as additional
>     arguments. What I can tell you is, per the script excerpt I shared
>     last time, faust2teensy does indeed employ the -uim flag
>     implicitly by default (i.e. specifying it explicitly would be
>     redundant). To answer your question, yes when you click the truck
>     icon, select teensy as your Platform and cilck /Compile/,
>     faust2teensy is executed and your code benefits from application
>     of the -uim flag.
>
>     I've been following this discussion with some curiosity because I
>     work with the Teensy and have a Faust algorithm with 30+ UI
>     elements that runs fine. Where I run into problems is with delay
>     lines (due to memory limitations posed by the Teensy — though
>     experimenting with adding extra PSRAM has shown promise) and
>     parameter smoothing (I avoid si.smoo and do my smoothing
>     /outside/ of Faust). Does your generated C++ code exhibit any
>     large arrays? If so, have you experimented with the -dlt flag?
>
>     Cheers,
>
>     Tommy
>
>     Le 06/03/2026 à 13:30, Tejas Rode a écrit :
>>     The documentation on faust for teensy
>>     https://faustdoc.grame.fr/tutorials/teensy/ states that the
>>     command run with the truck icon is:
>>
>>     faust2teensy -lib FaustTriangle.dsp
>>
>>     The git
>>     https://github.com/grame-cncm/faust/tree/master-dev/architecture/teensy
>>     doesn't mention -uim as an available option for faust2teensy,
>>     though it is available for faust in general
>>     https://faustdoc.grame.fr/manual/options/
>>
>>     This means that more than 3 instances are really not possible
>>     with the current state of faust2teensy.
>>
>>     Thank you all for helping with this!
>>     Tejas
>>
>>     On Thu, Mar 5, 2026 at 2:24 PM Tejas Rode <tej...@gm...>
>>     wrote:
>>
>>         Great conversation and inputs!
>>
>>         Tommy, is the -uim flag implicitly used when I click on the
>>         'truck' icon and select 'teensy' in fausteditor online? If
>>         not, how could I enable it? Since I'm new to faust, I'll need
>>         some direction there.
>>
>>         If, in the end, the upper limit on the number of instances of
>>         alias-suppressed triangle acts as a roadblock, I'll have to
>>         unfortunately move away from faust, and rely on what native
>>         teensy functions can do.
>>
>>         Thanks,
>>         Tejas
>>
>>         On Thu, Mar 5, 2026 at 10:22 AM Tommy Rushton
>>         <tom...@gm...> wrote:
>>
>>>             The -uim option already generates lightweight C macros
>>>             as an alternative, but no embedded architecture
>>>             currently uses it.
>>             On the contrary, faust2teensy uses this flag...
>>
>>             if [ $LIB -eq1 ];then mkdir -p $MODULENAME
>>                  faust $OPTIONS -uim -a $FAUSTARCH/teensy/teensy.cpp -i $FILE -o $MODULENAME/$MODULENAME.cpp
>>
>>             etc.
>>
>>             Cheers,
>>
>>             Tommy
>>
>>
>>             Le 05/03/2026 à 16:28, Julius Smith a écrit :
>>
>>>             > Can Gemini help ((-: ?
>>>
>>>             Absolutely!  However, for software development, I prefer
>>>             Claude Opus 4.6 (with "thinking" enabled liberally). 
>>>             Here is Claude's first take:
>>>
>>>             Prompt:
>>>             > Research existing Faust architecture files for
>>>             embedded targets to understand what currently exists
>>>
>>>             Reply:
>>>             Here is an overview of existing Faust architecture files
>>>             for embedded platforms, compiled by browsing the Faust
>>>             GitHub repo and documentation site.
>>>
>>>             OVERVIEW OF EXISTING FAUST ARCHITECTURE FILES FOR
>>>             EMBEDDED PROCESSORS
>>>             =====================================================================
>>>
>>>             THE CURRENT LANDSCAPE
>>>
>>>             Faust currently targets seven embedded/microcontroller
>>>             platforms through dedicated architecture files and
>>>             faust2xx scripts. Each has its own directory under
>>>             architecture/ in the Faust repo, plus a corresponding
>>>             faust2xx script in tools/faust2appls/. Here is what exists:
>>>
>>>
>>>             1. TEENSY (architecture/teensy/)
>>>
>>>             Files: teensy.cpp, teensy.h, README
>>>             Last updated: Nov 2023 (3 years ago)
>>>             Script: faust2teensy [-lib] [-midi] [-nvoices <num>]
>>>
>>>             Generates objects compatible with the PJRC Teensy Audio
>>>             Library. The generated C++ class derives from
>>>             AudioStream and uses setParamValue with string-matching
>>>             metadata tables to expose hslider/nentry/vslider
>>>             controls. Supports Teensy 3.6 and 4.x (FPU required).
>>>             Has a tutorial on the Faust documentation site. Key
>>>             limitations (as exposed in this email thread): the UI
>>>             metadata/control structure (string-matching table for
>>>             setParamValue) creates substantial overhead, limiting
>>>             the number of instances that can run concurrently. No
>>>             -mem or -sdram option support.
>>>
>>>
>>>             2. DAISY (architecture/daisy/)
>>>
>>>             Files: ex_faust.cpp, Makefile, faust_daisy_mem.py, README
>>>             Last updated: Dec 2025 (3 months ago, actively maintained)
>>>             Script: faust2daisy [-patch] [-pod] [-patchsm] [-sdram]
>>>             [-mem-thresh <num>] [-midi] [-nvoices <num>] [-sr <num>]
>>>             [-bs <num>] [-sram] [-qspi]
>>>
>>>             Supports Electrosmith Daisy Seed, Pod, Patch, and
>>>             Patch.Init() boards. Has the most sophisticated embedded
>>>             memory handling: a Python script (faust_daisy_mem.py)
>>>             post-processes generated C++ to move large buffers to
>>>             SDRAM. Supports multiple flash modes (FLASH, SRAM,
>>>             QSPI). Uses custom DaisyControlUI.h and daisy-midi.h
>>>             headers. The README notes an active refactoring
>>>             underway, with planned features including more compact
>>>             code, static memory allocation, and MIDI polyphonic
>>>             support. No tutorial on the Faust documentation site.
>>>
>>>
>>>             3. ESP32 (architecture/esp32/)
>>
>>>             Re. the latter, since si.smoo works on a per-sample
>>>             basis it's way too heavy for the Teensy's CPU (picture
>>>             trying to smooth the XY-coordinates of 16 virtual sound
>>>             sources), so I take a hybrid approach and do my
>>>             parameter smoothing outside of Faust
>>
>>>             Script: faust2esp32 [-lib] [-gramophone] [-multi]
>>>             [-midi] [-nvoices <num>] [-wm8978 or -ac101]
>>>
>>>             Targets the Espressif ESP32 family. Generates a C++
>>>             class and audio codec configuration objects. Currently
>>>             supports the Wolfson WM8978 (TTGO T-Audio) and AC101
>>>             codecs. Has a dedicated GRAME "Gramophone" mode. Has a
>>>             tutorial on the Faust documentation site. Includes a
>>>             drivers/ folder with codec-specific documentation.
>>>
>>>
>>>             4. HOTHOUSE (architecture/hothouse/)
>>>
>>>             Script: faust2hothouse [-midi] [-nvoices <num>] [-sr
>>>             <num>] [-bs <num>]
>>>
>>>             Targets the Cleveland Music Co. Hothouse DIY Pedal
>>>             (Daisy-based). Supports 6 knobs, 3 toggle switches, and
>>>             2 foot switches via [knob:N], [toggle:N], [foot:N]
>>>             metadata. Uses a Python script for SDRAM placement of
>>>             large buffers (same approach as Daisy). Uses custom
>>>             HothouseControlUI.h and shares daisy-midi.h with the
>>>             Daisy architecture. Relatively recent addition.
>>>
>>>
>>>             5. BELA (architecture/bela.cpp)
>>>
>>>             Script: faust2bela
>>>
>>>             A single architecture file for the Bela platform
>>>             (BeagleBone Black-based). Bela is more of an embedded
>>>             Linux system than a bare-metal microcontroller, so it
>>>             has more resources available. Architecture file was last
>>>             touched in April 2024.
>>>
>>>
>>>             6. OWL (architecture/owl.cpp)
>>>
>>>             Script: faust2owl
>>>
>>>             Targets the Rebel Technology OWL platform. Notable
>>>             because it already implements a custom OwlMemoryManager
>>>             (using the Faust -mem memory manager API), making it one
>>>             of the few embedded architectures that leverages the
>>>             custom memory allocation infrastructure. Single file
>>>             architecture.
>>>
>>>
>>>             7. CHAOS STRATUS (architecture/chaos-stratus/)
>>>
>>>             Script: faust2stratus
>>>
>>>             Targets the Chaos Audio Stratus guitar pedal. Uses a
>>>             Linux-based embedded system with SSH/SCP deployment.
>>>             Architecture includes build scripts, Docker support for
>>>             cross-compilation, and a stratus.cpp file. Relatively
>>>             sophisticated deployment pipeline.
>>>
>>>
>>>             8. SAM (architecture/sam/)
>>>
>>>             An older, apparently less-maintained architecture (last
>>>             commit from 2019).
>>>
>>>
>>>             CROSS-CUTTING INFRASTRUCTURE ALREADY AVAILABLE
>>>             ===============================================
>>>
>>>             The Faust compiler already provides several features
>>>             that are relevant to embedded targets but are NOT
>>>             uniformly exploited across all embedded architectures:
>>>
>>>             The -mem / --memory-manager option: Generates code where
>>>             large arrays become pointers allocated via an external
>>>             dsp_memory_manager. This enables distributing DSP memory
>>>             across SRAM/SDRAM/DTCM. The memoryInfo() method provides
>>>             detailed information about each zone's size and
>>>             read/write access patterns. Currently only the OWL
>>>             architecture actually uses this. The Daisy architecture
>>>             works around the same problem with a Python
>>>             post-processing script instead.
>>>
>>>             The -uim option: Generates static C preprocessor macros
>>>             (FAUST_ADDHORIZONTALSLIDER, FAUST_LIST_ACTIVES, etc.)
>>>             that describe control parameters without requiring the
>>>             full UI class hierarchy. This is ideal for embedded
>>>             platforms where you don't need a graphical UI and want
>>>             to avoid the overhead of buildUserInterface and its
>>>             metadata tables. Demonstrated in minimal-static.cpp but
>>>             not used by any current embedded architecture.
>>>
>>>             The -inpl (in-place) option: Generates code where input
>>>             and output buffers can be the same memory -- noted in
>>>             the docs as being "typically needed in some embedded
>>>             devices." Only works in scalar mode.
>>>
>>>             The C backend (-lang c): Can generate pure C code
>>>             instead of C++, avoiding C++ runtime overhead (vtables,
>>>             exceptions, RTTI, stdio, etc.). Uses CGlue.h and
>>>             CInterface.h. Not currently used by any embedded
>>>             architecture.
>>>
>>>             Metadata conventions: A common set of [switch:N],
>>>             [knob:N] metadata has been defined for devices without
>>>             screens. The Hothouse extends this with [toggle:N] and
>>>             [foot:N]. The documentation notes that this set "will
>>>             probably have to be progressively defined and standardized."
>>>
>>>             JSON memory layout: When using -mem -json, the complete
>>>             memory layout is emitted in JSON, allowing compile-time
>>>             memory planning (e.g., using #pragma directives for
>>>             memory segments). This enables hybrid static/dynamic
>>>             memory management.
>>>
>>>
>>>             GAPS AND OPPORTUNITIES (What Stephane Is Calling For)
>>>             =====================================================
>>>
>>>             Based on this survey, the key gaps that new "embedded
>>>             hardware aware" architecture files could address:
>>>
>>>             UI overhead problem: The Teensy thread exposed this
>>>             directly -- the standard buildUserInterface /
>>>             setParamValue / string-matching metadata table approach
>>>             creates significant memory and code overhead. The -uim
>>>             option already generates lightweight C macros as an
>>>             alternative, but no embedded architecture currently uses it.
>>>
>>>             No uniform memory management: Each platform handles
>>>             memory constraints differently -- Daisy uses a Python
>>>             post-processor, OWL uses -mem with a custom allocator,
>>>             Teensy has no solution at all. A unified approach using
>>>             -mem with platform-specific allocators would be cleaner.
>>>
>>>             C++ library bloat: As Stephane noted, even using stdio
>>>             can produce huge binaries. The C backend (-lang c) could
>>>             help, but there are no architecture files that use it
>>>             for embedded targets. Raw C output combined with -uim
>>>             macros could produce dramatically smaller binaries.
>>>
>>>             Inconsistent feature support: The Daisy architecture is
>>>             the most complete (SDRAM support, multiple board
>>>             variants, flash modes, active refactoring), while Teensy
>>>             hasn't been touched in over 3 years. No embedded
>>>             architecture supports the -mem option uniformly.
>>>
>>>             No Pico DSP architecture: Despite being mentioned in the
>>>             Faust documentation's embedded platforms section, there
>>>             is no faust2pico or Pico architecture directory.
>>>
>>>             Limited documentation: Only Teensy and ESP32 have
>>>             tutorials on the Faust documentation site. No Daisy
>>>             tutorial exists despite it being the most actively
>>>             developed embedded target.
>>>
>>>
>>>             _______________________________________________
>>>             Faudiostream-users mailing list
>>>             Fau...@li...
>>>             https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>             _______________________________________________
>>             Faudiostream-users mailing list
>>             Fau...@li...
>>             https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>

Re: [Faudiostream-users] New: Raspberry PI 5 (or 4B) for Faust

[Julius S. <jul...@gm...>]

Hi All,

VBAP is in hoa.lib - here's my trivial test program for stereo (based on
the one in the doc):

ho = library("hoa.lib");
os = library("oscillators.lib");
angle = hslider("angle",0,-60,60,1);
amp = hslider("amp",0.1,0,1,0.001);
freq = hslider("freq",100,20,2000,1);

circularScaledVBAP_test = amp * os.sawtooth(freq) : ho.circularScaledVBAP((-
60, 60), angle);
process = circularScaledVBAP_test;

On Fri, Mar 6, 2026 at 6:02 AM Marc Lavallée via Faudiostream-users <
fau...@li...> wrote:

> Le 2026-03-06 à 07 h 57, Joachim Kröger a écrit :
>
> Let me add a question:  I use panning to move between 2 channels. But my
> intention is, to distribute between 8 channels, in order to make a sound
> location, projection in the room.
>
> How can I accomplish that?
>
> The location in the room is measured, calculated outside of Faust, then it
> shall be applied, inserted into Faust interfaces.
> Greetings, Joachim
>
> Hi Joachim,
>
> Projecting sound into a room can be accomplished using WFS (Wave Field
> Synthesis) but with 8 loudspeakers there would be very little spatial
> resolution at higher frequencies. If panning sound between loudspeakers is
> enough, try VBAP (Vector base amplitude panning). I'm not aware of an
> implementation of VBAP for Faust; the original one is for MATLAB, one is
> for PureData, another is for SuperCollider... There's also Ambisonics but I
> would not recommend it for a "sound installation".
>
> Am 6. März 2026 01:54:09 schrieb Joachim Kröger <kr...@po...>
> <kr...@po...>:
>
>> My very first questions are focused to faust dsp on the PI.and difference
>> between jach and ALSA. I did not try faust to run on the PI so far!
>> Can you propose steps to configure my system?
>>
> Try to avoid Jack or Pipewire because it adds complexity and latency.
> Using a Pi5 could help.
>
> The CMedia chipset seems to have broad support. It is heart of my tested
>> adapters.
>> Sound quality is not critical, but fluent, reliable work and: cost
>> effective solution is a must.
>>
> I also use cheap USB sound modules (based on the CMedia chip); I agree
> that 16bit/44KHz is good enough, but the main issue with such cheap modules
> is noise, so if sound levels and dynamics are kept low they work well
> enough. I use 3 in parallel for 24 channels but their clocks are not
> in sync so it limits what I can do.
>
> Any tips are welcome!
>>
> I'm not helping a lot, but I wonder: why do you need Faust?
>
> Marc
> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
AI has taken my job, but only I know what it is.

Re: [Faudiostream-users] Question about creating a triangle wave

[Tejas R. <tej...@gm...>]

Thank you Tommy!

Does your teensy use 30+ instances of ONE faust object? Have you tried
that? That’s where I’m stuck.

My teensy doesn’t have the extra PSRAM, so I’ll have to work with the
default. Also, I’m not yet doing si.smoo, but will avoid that. I don’t
think there are large arrays. You can take a look at my faust code from
this email thread.

Thanks,
Tejas


On Fri, Mar 6, 2026 at 8:36 AM Tommy Rushton <tom...@gm...>
wrote:

> Hi Tejas,
>
> The faust2[...] tools accept any valid Faust flags as additional
> arguments. What I can tell you is, per the script excerpt I shared last
> time, faust2teensy does indeed employ the -uim flag implicitly by default
> (i.e. specifying it explicitly would be redundant). To answer your
> question, yes when you click the truck icon, select teensy as your Platform
> and cilck *Compile*, faust2teensy is executed and your code benefits from
> application of the -uim flag.
>
> I've been following this discussion with some curiosity because I work
> with the Teensy and have a Faust algorithm with 30+ UI elements that runs
> fine. Where I run into problems is with delay lines (due to memory
> limitations posed by the Teensy — though experimenting with adding extra
> PSRAM has shown promise) and parameter smoothing (I avoid si.smoo and do my
> smoothing *outside* of Faust). Does your generated C++ code exhibit any
> large arrays? If so, have you experimented with the -dlt flag?
>
> Cheers,
>
> Tommy
> Le 06/03/2026 à 13:30, Tejas Rode a écrit :
>
> The documentation on faust for teensy
> https://faustdoc.grame.fr/tutorials/teensy/ states that the command run
> with the truck icon is:
>
> faust2teensy -lib FaustTriangle.dsp
>
> The git
> https://github.com/grame-cncm/faust/tree/master-dev/architecture/teensy
> doesn't mention -uim as an available option for faust2teensy, though it is
> available for faust in general https://faustdoc.grame.fr/manual/options/
>
> This means that more than 3 instances are really not possible with the
> current state of faust2teensy.
>
> Thank you all for helping with this!
> Tejas
>
> On Thu, Mar 5, 2026 at 2:24 PM Tejas Rode <tej...@gm...> wrote:
>
> Great conversation and inputs!
>>
>> Tommy, is the -uim flag implicitly used when I click on the 'truck' icon
>> and select 'teensy' in fausteditor online? If not, how could I enable it?
>> Since I'm new to faust, I'll need some direction there.
>>
>> If, in the end, the upper limit on the number of instances of
>> alias-suppressed triangle acts as a roadblock, I'll have to unfortunately
>> move away from faust, and rely on what native teensy functions can do.
>>
>> Thanks,
>> Tejas
>>
>> On Thu, Mar 5, 2026 at 10:22 AM Tommy Rushton <tom...@gm...>
>> wrote:
>>
> The -uim option already generates lightweight C macros as an alternative,
>>> but no embedded architecture currently uses it.
>>>
>>> On the contrary, faust2teensy uses this flag...
>>>
>>> if [ $LIB -eq 1 ]; then    mkdir -p $MODULENAME
>>>     faust $OPTIONS -uim -a $FAUSTARCH/teensy/teensy.cpp -i $FILE -o $MODULENAME/$MODULENAME.cpp
>>>
>>> etc.
>>>
>>> Cheers,
>>>
>>> Tommy
>>>
>>>
>>> Le 05/03/2026 à 16:28, Julius Smith a écrit :
>>>
>> > Can Gemini help ((-: ?
>>>
>>> Absolutely!  However, for software development, I prefer Claude Opus 4.6
>>> (with "thinking" enabled liberally).  Here is Claude's first take:
>>>
>>> Prompt:
>>> > Research existing Faust architecture files for embedded targets to
>>> understand what currently exists
>>>
>>> Reply:
>>> Here is an overview of existing Faust architecture files for embedded
>>> platforms, compiled by browsing the Faust GitHub repo and documentation
>>> site.
>>>
>>> OVERVIEW OF EXISTING FAUST ARCHITECTURE FILES FOR EMBEDDED PROCESSORS
>>> =====================================================================
>>>
>>> THE CURRENT LANDSCAPE
>>>
>>> Faust currently targets seven embedded/microcontroller platforms through
>>> dedicated architecture files and faust2xx scripts. Each has its own
>>> directory under architecture/ in the Faust repo, plus a corresponding
>>> faust2xx script in tools/faust2appls/. Here is what exists:
>>>
>>>
>>> 1. TEENSY (architecture/teensy/)
>>>
>>> Files: teensy.cpp, teensy.h, README
>>> Last updated: Nov 2023 (3 years ago)
>>> Script: faust2teensy [-lib] [-midi] [-nvoices <num>]
>>>
>>> Generates objects compatible with the PJRC Teensy Audio Library. The
>>> generated C++ class derives from AudioStream and uses setParamValue with
>>> string-matching metadata tables to expose hslider/nentry/vslider controls.
>>> Supports Teensy 3.6 and 4.x (FPU required). Has a tutorial on the Faust
>>> documentation site. Key limitations (as exposed in this email thread): the
>>> UI metadata/control structure (string-matching table for setParamValue)
>>> creates substantial overhead, limiting the number of instances that can run
>>> concurrently. No -mem or -sdram option support.
>>>
>>>
>>> 2. DAISY (architecture/daisy/)
>>>
>>> Files: ex_faust.cpp, Makefile, faust_daisy_mem.py, README
>>> Last updated: Dec 2025 (3 months ago, actively maintained)
>>> Script: faust2daisy [-patch] [-pod] [-patchsm] [-sdram] [-mem-thresh
>>> <num>] [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>] [-sram] [-qspi]
>>>
>>> Supports Electrosmith Daisy Seed, Pod, Patch, and Patch.Init() boards.
>>> Has the most sophisticated embedded memory handling: a Python script
>>> (faust_daisy_mem.py) post-processes generated C++ to move large buffers to
>>> SDRAM. Supports multiple flash modes (FLASH, SRAM, QSPI). Uses custom
>>> DaisyControlUI.h and daisy-midi.h headers. The README notes an active
>>> refactoring underway, with planned features including more compact code,
>>> static memory allocation, and MIDI polyphonic support. No tutorial on the
>>> Faust documentation site.
>>>
>>>
>>> 3. ESP32 (architecture/esp32/)
>>>
>>> Re. the latter, since si.smoo works on a per-sample basis it's way too
>>> heavy for the Teensy's CPU (picture trying to smooth the XY-coordinates of
>>> 16 virtual sound sources), so I take a hybrid approach and do my parameter
>>> smoothing outside of Faust
>>>
>>> Script: faust2esp32 [-lib] [-gramophone] [-multi] [-midi] [-nvoices
>>> <num>] [-wm8978 or -ac101]
>>>
>>> Targets the Espressif ESP32 family. Generates a C++ class and audio
>>> codec configuration objects. Currently supports the Wolfson WM8978 (TTGO
>>> T-Audio) and AC101 codecs. Has a dedicated GRAME "Gramophone" mode. Has a
>>> tutorial on the Faust documentation site. Includes a drivers/ folder with
>>> codec-specific documentation.
>>>
>>>
>>> 4. HOTHOUSE (architecture/hothouse/)
>>>
>>> Script: faust2hothouse [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>]
>>>
>>> Targets the Cleveland Music Co. Hothouse DIY Pedal (Daisy-based).
>>> Supports 6 knobs, 3 toggle switches, and 2 foot switches via [knob:N],
>>> [toggle:N], [foot:N] metadata. Uses a Python script for SDRAM placement of
>>> large buffers (same approach as Daisy). Uses custom HothouseControlUI.h and
>>> shares daisy-midi.h with the Daisy architecture. Relatively recent addition.
>>>
>>>
>>> 5. BELA (architecture/bela.cpp)
>>>
>>> Script: faust2bela
>>>
>>> A single architecture file for the Bela platform (BeagleBone
>>> Black-based). Bela is more of an embedded Linux system than a bare-metal
>>> microcontroller, so it has more resources available. Architecture file was
>>> last touched in April 2024.
>>>
>>>
>>> 6. OWL (architecture/owl.cpp)
>>>
>>> Script: faust2owl
>>>
>>> Targets the Rebel Technology OWL platform. Notable because it already
>>> implements a custom OwlMemoryManager (using the Faust -mem memory manager
>>> API), making it one of the few embedded architectures that leverages the
>>> custom memory allocation infrastructure. Single file architecture.
>>>
>>>
>>> 7. CHAOS STRATUS (architecture/chaos-stratus/)
>>>
>>> Script: faust2stratus
>>>
>>> Targets the Chaos Audio Stratus guitar pedal. Uses a Linux-based
>>> embedded system with SSH/SCP deployment. Architecture includes build
>>> scripts, Docker support for cross-compilation, and a stratus.cpp file.
>>> Relatively sophisticated deployment pipeline.
>>>
>>>
>>> 8. SAM (architecture/sam/)
>>>
>>> An older, apparently less-maintained architecture (last commit from
>>> 2019).
>>>
>>>
>>> CROSS-CUTTING INFRASTRUCTURE ALREADY AVAILABLE
>>> ===============================================
>>>
>>> The Faust compiler already provides several features that are relevant
>>> to embedded targets but are NOT uniformly exploited across all embedded
>>> architectures:
>>>
>>> The -mem / --memory-manager option: Generates code where large arrays
>>> become pointers allocated via an external dsp_memory_manager. This enables
>>> distributing DSP memory across SRAM/SDRAM/DTCM. The memoryInfo() method
>>> provides detailed information about each zone's size and read/write access
>>> patterns. Currently only the OWL architecture actually uses this. The Daisy
>>> architecture works around the same problem with a Python post-processing
>>> script instead.
>>>
>>> The -uim option: Generates static C preprocessor macros
>>> (FAUST_ADDHORIZONTALSLIDER, FAUST_LIST_ACTIVES, etc.) that describe control
>>> parameters without requiring the full UI class hierarchy. This is ideal for
>>> embedded platforms where you don't need a graphical UI and want to avoid
>>> the overhead of buildUserInterface and its metadata tables. Demonstrated in
>>> minimal-static.cpp but not used by any current embedded architecture.
>>>
>>> The -inpl (in-place) option: Generates code where input and output
>>> buffers can be the same memory -- noted in the docs as being "typically
>>> needed in some embedded devices." Only works in scalar mode.
>>>
>>> The C backend (-lang c): Can generate pure C code instead of C++,
>>> avoiding C++ runtime overhead (vtables, exceptions, RTTI, stdio, etc.).
>>> Uses CGlue.h and CInterface.h. Not currently used by any embedded
>>> architecture.
>>>
>>> Metadata conventions: A common set of [switch:N], [knob:N] metadata has
>>> been defined for devices without screens. The Hothouse extends this with
>>> [toggle:N] and [foot:N]. The documentation notes that this set "will
>>> probably have to be progressively defined and standardized."
>>>
>>> JSON memory layout: When using -mem -json, the complete memory layout is
>>> emitted in JSON, allowing compile-time memory planning (e.g., using #pragma
>>> directives for memory segments). This enables hybrid static/dynamic memory
>>> management.
>>>
>>>
>>> GAPS AND OPPORTUNITIES (What Stephane Is Calling For)
>>> =====================================================
>>>
>>> Based on this survey, the key gaps that new "embedded hardware aware"
>>> architecture files could address:
>>>
>>> UI overhead problem: The Teensy thread exposed this directly -- the
>>> standard buildUserInterface / setParamValue / string-matching metadata
>>> table approach creates significant memory and code overhead. The -uim
>>> option already generates lightweight C macros as an alternative, but no
>>> embedded architecture currently uses it.
>>>
>>> No uniform memory management: Each platform handles memory constraints
>>> differently -- Daisy uses a Python post-processor, OWL uses -mem with a
>>> custom allocator, Teensy has no solution at all. A unified approach using
>>> -mem with platform-specific allocators would be cleaner.
>>>
>>> C++ library bloat: As Stephane noted, even using stdio can produce huge
>>> binaries. The C backend (-lang c) could help, but there are no architecture
>>> files that use it for embedded targets. Raw C output combined with -uim
>>> macros could produce dramatically smaller binaries.
>>>
>>> Inconsistent feature support: The Daisy architecture is the most
>>> complete (SDRAM support, multiple board variants, flash modes, active
>>> refactoring), while Teensy hasn't been touched in over 3 years. No embedded
>>> architecture supports the -mem option uniformly.
>>>
>>> No Pico DSP architecture: Despite being mentioned in the Faust
>>> documentation's embedded platforms section, there is no faust2pico or Pico
>>> architecture directory.
>>>
>>> Limited documentation: Only Teensy and ESP32 have tutorials on the Faust
>>> documentation site. No Daisy tutorial exists despite it being the most
>>> actively developed embedded target.
>>>
>>>
>>> _______________________________________________
>>> Faudiostream-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>
>>> _______________________________________________
>>> Faudiostream-users mailing list
>>> Fau...@li...
>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>
>>

Re: [Faudiostream-users] Question about creating a triangle wave

[Tommy R. <tom...@gm...>]

Hi Tejas,

The faust2[...] tools accept any valid Faust flags as additional 
arguments. What I can tell you is, per the script excerpt I shared last 
time, faust2teensy does indeed employ the -uim flag implicitly by 
default (i.e. specifying it explicitly would be redundant). To answer 
your question, yes when you click the truck icon, select teensy as your 
Platform and cilck /Compile/, faust2teensy is executed and your code 
benefits from application of the -uim flag.

I've been following this discussion with some curiosity because I work 
with the Teensy and have a Faust algorithm with 30+ UI elements that 
runs fine. Where I run into problems is with delay lines (due to memory 
limitations posed by the Teensy — though experimenting with adding extra 
PSRAM has shown promise) and parameter smoothing (I avoid si.smoo and do 
my smoothing /outside/ of Faust). Does your generated C++ code exhibit 
any large arrays? If so, have you experimented with the -dlt flag?

Cheers,

Tommy

Le 06/03/2026 à 13:30, Tejas Rode a écrit :
> The documentation on faust for teensy 
> https://faustdoc.grame.fr/tutorials/teensy/ states that the command 
> run with the truck icon is:
>
> faust2teensy -lib FaustTriangle.dsp
>
> The git 
> https://github.com/grame-cncm/faust/tree/master-dev/architecture/teensy 
> doesn't mention -uim as an available option for faust2teensy, though 
> it is available for faust in general 
> https://faustdoc.grame.fr/manual/options/
>
> This means that more than 3 instances are really not possible with the 
> current state of faust2teensy.
>
> Thank you all for helping with this!
> Tejas
>
> On Thu, Mar 5, 2026 at 2:24 PM Tejas Rode <tej...@gm...> wrote:
>
>     Great conversation and inputs!
>
>     Tommy, is the -uim flag implicitly used when I click on the
>     'truck' icon and select 'teensy' in fausteditor online? If not,
>     how could I enable it? Since I'm new to faust, I'll need some
>     direction there.
>
>     If, in the end, the upper limit on the number of instances of
>     alias-suppressed triangle acts as a roadblock, I'll have to
>     unfortunately move away from faust, and rely on what native teensy
>     functions can do.
>
>     Thanks,
>     Tejas
>
>     On Thu, Mar 5, 2026 at 10:22 AM Tommy Rushton
>     <tom...@gm...> wrote:
>
>>         The -uim option already generates lightweight C macros as an
>>         alternative, but no embedded architecture currently uses it.
>         On the contrary, faust2teensy uses this flag...
>
>         if [ $LIB -eq1 ];then mkdir -p $MODULENAME
>              faust $OPTIONS -uim -a $FAUSTARCH/teensy/teensy.cpp -i $FILE -o $MODULENAME/$MODULENAME.cpp
>
>         etc.
>
>         Cheers,
>
>         Tommy
>
>
>         Le 05/03/2026 à 16:28, Julius Smith a écrit :
>>         > Can Gemini help ((-: ?
>>
>>         Absolutely!  However, for software development, I prefer
>>         Claude Opus 4.6 (with "thinking" enabled liberally).  Here is
>>         Claude's first take:
>>
>>         Prompt:
>>         > Research existing Faust architecture files for embedded
>>         targets to understand what currently exists
>>
>>         Reply:
>>         Here is an overview of existing Faust architecture files for
>>         embedded platforms, compiled by browsing the Faust GitHub
>>         repo and documentation site.
>>
>>         OVERVIEW OF EXISTING FAUST ARCHITECTURE FILES FOR EMBEDDED
>>         PROCESSORS
>>         =====================================================================
>>
>>         THE CURRENT LANDSCAPE
>>
>>         Faust currently targets seven embedded/microcontroller
>>         platforms through dedicated architecture files and faust2xx
>>         scripts. Each has its own directory under architecture/ in
>>         the Faust repo, plus a corresponding faust2xx script in
>>         tools/faust2appls/. Here is what exists:
>>
>>
>>         1. TEENSY (architecture/teensy/)
>>
>>         Files: teensy.cpp, teensy.h, README
>>         Last updated: Nov 2023 (3 years ago)
>>         Script: faust2teensy [-lib] [-midi] [-nvoices <num>]
>>
>>         Generates objects compatible with the PJRC Teensy Audio
>>         Library. The generated C++ class derives from AudioStream and
>>         uses setParamValue with string-matching metadata tables to
>>         expose hslider/nentry/vslider controls. Supports Teensy 3.6
>>         and 4.x (FPU required). Has a tutorial on the Faust
>>         documentation site. Key limitations (as exposed in this email
>>         thread): the UI metadata/control structure (string-matching
>>         table for setParamValue) creates substantial overhead,
>>         limiting the number of instances that can run concurrently.
>>         No -mem or -sdram option support.
>>
>>
>>         2. DAISY (architecture/daisy/)
>>
>>         Files: ex_faust.cpp, Makefile, faust_daisy_mem.py, README
>>         Last updated: Dec 2025 (3 months ago, actively maintained)
>>         Script: faust2daisy [-patch] [-pod] [-patchsm] [-sdram]
>>         [-mem-thresh <num>] [-midi] [-nvoices <num>] [-sr <num>] [-bs
>>         <num>] [-sram] [-qspi]
>>
>>         Supports Electrosmith Daisy Seed, Pod, Patch, and
>>         Patch.Init() boards. Has the most sophisticated embedded
>>         memory handling: a Python script (faust_daisy_mem.py)
>>         post-processes generated C++ to move large buffers to SDRAM.
>>         Supports multiple flash modes (FLASH, SRAM, QSPI). Uses
>>         custom DaisyControlUI.h and daisy-midi.h headers. The README
>>         notes an active refactoring underway, with planned features
>>         including more compact code, static memory allocation, and
>>         MIDI polyphonic support. No tutorial on the Faust
>>         documentation site.
>>
>>
>>         3. ESP32 (architecture/esp32/)
>>         Re. the latter, since si.smoo works on a per-sample basis
>>         it's way too heavy for the Teensy's CPU (picture trying to
>>         smooth the XY-coordinates of 16 virtual sound sources), so I
>>         take a hybrid approach and do my parameter smoothing outside
>>         of Faust
>>         Script: faust2esp32 [-lib] [-gramophone] [-multi] [-midi]
>>         [-nvoices <num>] [-wm8978 or -ac101]
>>
>>         Targets the Espressif ESP32 family. Generates a C++ class and
>>         audio codec configuration objects. Currently supports the
>>         Wolfson WM8978 (TTGO T-Audio) and AC101 codecs. Has a
>>         dedicated GRAME "Gramophone" mode. Has a tutorial on the
>>         Faust documentation site. Includes a drivers/ folder with
>>         codec-specific documentation.
>>
>>
>>         4. HOTHOUSE (architecture/hothouse/)
>>
>>         Script: faust2hothouse [-midi] [-nvoices <num>] [-sr <num>]
>>         [-bs <num>]
>>
>>         Targets the Cleveland Music Co. Hothouse DIY Pedal
>>         (Daisy-based). Supports 6 knobs, 3 toggle switches, and 2
>>         foot switches via [knob:N], [toggle:N], [foot:N] metadata.
>>         Uses a Python script for SDRAM placement of large buffers
>>         (same approach as Daisy). Uses custom HothouseControlUI.h and
>>         shares daisy-midi.h with the Daisy architecture. Relatively
>>         recent addition.
>>
>>
>>         5. BELA (architecture/bela.cpp)
>>
>>         Script: faust2bela
>>
>>         A single architecture file for the Bela platform (BeagleBone
>>         Black-based). Bela is more of an embedded Linux system than a
>>         bare-metal microcontroller, so it has more resources
>>         available. Architecture file was last touched in April 2024.
>>
>>
>>         6. OWL (architecture/owl.cpp)
>>
>>         Script: faust2owl
>>
>>         Targets the Rebel Technology OWL platform. Notable because it
>>         already implements a custom OwlMemoryManager (using the Faust
>>         -mem memory manager API), making it one of the few embedded
>>         architectures that leverages the custom memory allocation
>>         infrastructure. Single file architecture.
>>
>>
>>         7. CHAOS STRATUS (architecture/chaos-stratus/)
>>
>>         Script: faust2stratus
>>
>>         Targets the Chaos Audio Stratus guitar pedal. Uses a
>>         Linux-based embedded system with SSH/SCP deployment.
>>         Architecture includes build scripts, Docker support for
>>         cross-compilation, and a stratus.cpp file. Relatively
>>         sophisticated deployment pipeline.
>>
>>
>>         8. SAM (architecture/sam/)
>>
>>         An older, apparently less-maintained architecture (last
>>         commit from 2019).
>>
>>
>>         CROSS-CUTTING INFRASTRUCTURE ALREADY AVAILABLE
>>         ===============================================
>>
>>         The Faust compiler already provides several features that are
>>         relevant to embedded targets but are NOT uniformly exploited
>>         across all embedded architectures:
>>
>>         The -mem / --memory-manager option: Generates code where
>>         large arrays become pointers allocated via an external
>>         dsp_memory_manager. This enables distributing DSP memory
>>         across SRAM/SDRAM/DTCM. The memoryInfo() method provides
>>         detailed information about each zone's size and read/write
>>         access patterns. Currently only the OWL architecture actually
>>         uses this. The Daisy architecture works around the same
>>         problem with a Python post-processing script instead.
>>
>>         The -uim option: Generates static C preprocessor macros
>>         (FAUST_ADDHORIZONTALSLIDER, FAUST_LIST_ACTIVES, etc.) that
>>         describe control parameters without requiring the full UI
>>         class hierarchy. This is ideal for embedded platforms where
>>         you don't need a graphical UI and want to avoid the overhead
>>         of buildUserInterface and its metadata tables. Demonstrated
>>         in minimal-static.cpp but not used by any current embedded
>>         architecture.
>>
>>         The -inpl (in-place) option: Generates code where input and
>>         output buffers can be the same memory -- noted in the docs as
>>         being "typically needed in some embedded devices." Only works
>>         in scalar mode.
>>
>>         The C backend (-lang c): Can generate pure C code instead of
>>         C++, avoiding C++ runtime overhead (vtables, exceptions,
>>         RTTI, stdio, etc.). Uses CGlue.h and CInterface.h. Not
>>         currently used by any embedded architecture.
>>
>>         Metadata conventions: A common set of [switch:N], [knob:N]
>>         metadata has been defined for devices without screens. The
>>         Hothouse extends this with [toggle:N] and [foot:N]. The
>>         documentation notes that this set "will probably have to be
>>         progressively defined and standardized."
>>
>>         JSON memory layout: When using -mem -json, the complete
>>         memory layout is emitted in JSON, allowing compile-time
>>         memory planning (e.g., using #pragma directives for memory
>>         segments). This enables hybrid static/dynamic memory management.
>>
>>
>>         GAPS AND OPPORTUNITIES (What Stephane Is Calling For)
>>         =====================================================
>>
>>         Based on this survey, the key gaps that new "embedded
>>         hardware aware" architecture files could address:
>>
>>         UI overhead problem: The Teensy thread exposed this directly
>>         -- the standard buildUserInterface / setParamValue /
>>         string-matching metadata table approach creates significant
>>         memory and code overhead. The -uim option already generates
>>         lightweight C macros as an alternative, but no embedded
>>         architecture currently uses it.
>>
>>         No uniform memory management: Each platform handles memory
>>         constraints differently -- Daisy uses a Python
>>         post-processor, OWL uses -mem with a custom allocator, Teensy
>>         has no solution at all. A unified approach using -mem with
>>         platform-specific allocators would be cleaner.
>>
>>         C++ library bloat: As Stephane noted, even using stdio can
>>         produce huge binaries. The C backend (-lang c) could help,
>>         but there are no architecture files that use it for embedded
>>         targets. Raw C output combined with -uim macros could produce
>>         dramatically smaller binaries.
>>
>>         Inconsistent feature support: The Daisy architecture is the
>>         most complete (SDRAM support, multiple board variants, flash
>>         modes, active refactoring), while Teensy hasn't been touched
>>         in over 3 years. No embedded architecture supports the -mem
>>         option uniformly.
>>
>>         No Pico DSP architecture: Despite being mentioned in the
>>         Faust documentation's embedded platforms section, there is no
>>         faust2pico or Pico architecture directory.
>>
>>         Limited documentation: Only Teensy and ESP32 have tutorials
>>         on the Faust documentation site. No Daisy tutorial exists
>>         despite it being the most actively developed embedded target.
>>
>>
>>         _______________________________________________
>>         Faudiostream-users mailing list
>>         Fau...@li...
>>         https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>         _______________________________________________
>         Faudiostream-users mailing list
>         Fau...@li...
>         https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>

Re: [Faudiostream-users] New: Raspberry PI 5 (or 4B) for Faust

[Marc L. <ma...@ha...>]

Le 2026-03-06 à 07 h 57, Joachim Kröger a écrit :

> Let me add a question:  I use panning to move between 2 channels. But 
> my intention is, to distribute between 8 channels, in order to make a 
> sound location, projection in the room.
>
> How can I accomplish that?
>
> The location in the room is measured, calculated outside of Faust, 
> then it shall be applied, inserted into Faust interfaces.
>
> Greetings, Joachim

Hi Joachim,

Projecting sound into a room can be accomplished using WFS (Wave Field 
Synthesis) but with 8 loudspeakers there would be very little spatial 
resolution at higher frequencies. If panning sound between loudspeakers 
is enough, try VBAP (Vector base amplitude panning). I'm not aware of an 
implementation of VBAP for Faust; the original one is for MATLAB, one is 
for PureData, another is for SuperCollider... There's also Ambisonics 
but I would not recommend it for a "sound installation".

> Am 6. März 2026 01:54:09 schrieb Joachim Kröger <kr...@po...>:
>
>> My very first questions are focused to faust dsp on the PI.and 
>> difference between jach and ALSA. I did not try faust to run on the 
>> PI so far!
>> Can you propose steps to configure my system?

Try to avoid Jack or Pipewire because it adds complexity and latency. 
Using a Pi5 could help.

>> The CMedia chipset seems to have broad support. It is heart of my 
>> tested adapters.
>> Sound quality is not critical, but fluent, reliable work and: cost 
>> effective solution is a must.

I also use cheap USB sound modules (based on the CMedia chip); I agree 
that 16bit/44KHz is good enough, but the main issue with such cheap 
modules is noise, so if sound levels and dynamics are kept low they work 
well enough. I use 3 in parallel for 24 channels but their clocks are 
not in sync so it limits what I can do.

>> Any tips are welcome!

I'm not helping a lot, but I wonder: why do you need Faust?

Marc

Re: [Faudiostream-users] New: Raspberry PI 5 (or 4B) for Faust

[Joachim K. <kr...@po...>]

Let me add a question:  I use panning to move between 2 channels. But my 
intention is, to distribute between 8 channels, in order to make a sound 
location, projection in the room.

How can I accomplish that?

The location in the room is measured, calculated outside of Faust, then it 
shall be applied, inserted into Faust interfaces.  Greetings, Joachim

Am 6. März 2026 01:54:09 schrieb Joachim Kröger <kr...@po...>:
> Hello, great folks!
>
> I am in the learncurve, steeper parts.
> I managed to get Faust code in the online editor and it sounds good on a PC 
> (stereo), sounds bad on a powerful Android (Samsung S22 ultra).
> I also managed to have a working 7.1 (8 channel sound files) USB soundcard 
> on a Raspberry PI 4B and ALSA.
> This is my target hardware.
> I pulled from the recent conversation, that I should move to jack libraries 
> in order to have a chance to have reliable output port numbering and a 
> working microphone input.
> I think about some more microphones and hope to connect them via USB, too.
> I have no clue, if this is easy to change, going from alsa to jack. I hope so.
>
> I intend to process midi as adjustment parameters, a midi keyboard with 
> dials for settings.
> Most important, the sound shall be moved in the room and I learned, there 
> is also an interface to osc library thru messages to the ports, where osc 
> is listening. The unit shall be controlled via http service, for some 
> settings, too.
> The Raspberry shall run all of this. I have in mind, to use a PI 5 with SSD 
> drive.
>
> My very first questions are focused to faust dsp on the PI.and difference 
> between jach and ALSA. I did not try faust to run on the PI so far!
> Can you propose steps to configure my system?
> The CMedia chipset seems to have broad support. It is heart of my tested 
> adapters.
> Sound quality is not critical, but fluent, reliable work and: cost 
> effective solution is a must.
> Any tips are welcome!
>
> Greetings from Hamburg
> Joachim
>
> Tel. +49 (0)171 822 4624
>
>
>
> Am 5. März 2026 22:26:00 schrieb Tejas Rode <tej...@gm...>:
>> Great conversation and inputs!
>
> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Question about creating a triangle wave

[Tejas R. <tej...@gm...>]

The documentation on faust for teensy
https://faustdoc.grame.fr/tutorials/teensy/ states that the command run
with the truck icon is:

faust2teensy -lib FaustTriangle.dsp

The git
https://github.com/grame-cncm/faust/tree/master-dev/architecture/teensy
doesn't mention -uim as an available option for faust2teensy, though it is
available for faust in general https://faustdoc.grame.fr/manual/options/

This means that more than 3 instances are really not possible with the
current state of faust2teensy.

Thank you all for helping with this!
Tejas

On Thu, Mar 5, 2026 at 2:24 PM Tejas Rode <tej...@gm...> wrote:

> Great conversation and inputs!
>
> Tommy, is the -uim flag implicitly used when I click on the 'truck' icon
> and select 'teensy' in fausteditor online? If not, how could I enable it?
> Since I'm new to faust, I'll need some direction there.
>
> If, in the end, the upper limit on the number of instances of
> alias-suppressed triangle acts as a roadblock, I'll have to unfortunately
> move away from faust, and rely on what native teensy functions can do.
>
> Thanks,
> Tejas
>
> On Thu, Mar 5, 2026 at 10:22 AM Tommy Rushton <tom...@gm...>
> wrote:
>
>> The -uim option already generates lightweight C macros as an alternative,
>> but no embedded architecture currently uses it.
>>
>> On the contrary, faust2teensy uses this flag...
>>
>> if [ $LIB -eq 1 ]; then    mkdir -p $MODULENAME
>>     faust $OPTIONS -uim -a $FAUSTARCH/teensy/teensy.cpp -i $FILE -o $MODULENAME/$MODULENAME.cpp
>>
>> etc.
>>
>> Cheers,
>>
>> Tommy
>>
>>
>> Le 05/03/2026 à 16:28, Julius Smith a écrit :
>>
>> > Can Gemini help ((-: ?
>>
>> Absolutely!  However, for software development, I prefer Claude Opus 4.6
>> (with "thinking" enabled liberally).  Here is Claude's first take:
>>
>> Prompt:
>> > Research existing Faust architecture files for embedded targets to
>> understand what currently exists
>>
>> Reply:
>> Here is an overview of existing Faust architecture files for embedded
>> platforms, compiled by browsing the Faust GitHub repo and documentation
>> site.
>>
>> OVERVIEW OF EXISTING FAUST ARCHITECTURE FILES FOR EMBEDDED PROCESSORS
>> =====================================================================
>>
>> THE CURRENT LANDSCAPE
>>
>> Faust currently targets seven embedded/microcontroller platforms through
>> dedicated architecture files and faust2xx scripts. Each has its own
>> directory under architecture/ in the Faust repo, plus a corresponding
>> faust2xx script in tools/faust2appls/. Here is what exists:
>>
>>
>> 1. TEENSY (architecture/teensy/)
>>
>> Files: teensy.cpp, teensy.h, README
>> Last updated: Nov 2023 (3 years ago)
>> Script: faust2teensy [-lib] [-midi] [-nvoices <num>]
>>
>> Generates objects compatible with the PJRC Teensy Audio Library. The
>> generated C++ class derives from AudioStream and uses setParamValue with
>> string-matching metadata tables to expose hslider/nentry/vslider controls.
>> Supports Teensy 3.6 and 4.x (FPU required). Has a tutorial on the Faust
>> documentation site. Key limitations (as exposed in this email thread): the
>> UI metadata/control structure (string-matching table for setParamValue)
>> creates substantial overhead, limiting the number of instances that can run
>> concurrently. No -mem or -sdram option support.
>>
>>
>> 2. DAISY (architecture/daisy/)
>>
>> Files: ex_faust.cpp, Makefile, faust_daisy_mem.py, README
>> Last updated: Dec 2025 (3 months ago, actively maintained)
>> Script: faust2daisy [-patch] [-pod] [-patchsm] [-sdram] [-mem-thresh
>> <num>] [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>] [-sram] [-qspi]
>>
>> Supports Electrosmith Daisy Seed, Pod, Patch, and Patch.Init() boards.
>> Has the most sophisticated embedded memory handling: a Python script
>> (faust_daisy_mem.py) post-processes generated C++ to move large buffers to
>> SDRAM. Supports multiple flash modes (FLASH, SRAM, QSPI). Uses custom
>> DaisyControlUI.h and daisy-midi.h headers. The README notes an active
>> refactoring underway, with planned features including more compact code,
>> static memory allocation, and MIDI polyphonic support. No tutorial on the
>> Faust documentation site.
>>
>>
>> 3. ESP32 (architecture/esp32/)
>>
>> Script: faust2esp32 [-lib] [-gramophone] [-multi] [-midi] [-nvoices
>> <num>] [-wm8978 or -ac101]
>>
>> Targets the Espressif ESP32 family. Generates a C++ class and audio codec
>> configuration objects. Currently supports the Wolfson WM8978 (TTGO T-Audio)
>> and AC101 codecs. Has a dedicated GRAME "Gramophone" mode. Has a tutorial
>> on the Faust documentation site. Includes a drivers/ folder with
>> codec-specific documentation.
>>
>>
>> 4. HOTHOUSE (architecture/hothouse/)
>>
>> Script: faust2hothouse [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>]
>>
>> Targets the Cleveland Music Co. Hothouse DIY Pedal (Daisy-based).
>> Supports 6 knobs, 3 toggle switches, and 2 foot switches via [knob:N],
>> [toggle:N], [foot:N] metadata. Uses a Python script for SDRAM placement of
>> large buffers (same approach as Daisy). Uses custom HothouseControlUI.h and
>> shares daisy-midi.h with the Daisy architecture. Relatively recent addition.
>>
>>
>> 5. BELA (architecture/bela.cpp)
>>
>> Script: faust2bela
>>
>> A single architecture file for the Bela platform (BeagleBone
>> Black-based). Bela is more of an embedded Linux system than a bare-metal
>> microcontroller, so it has more resources available. Architecture file was
>> last touched in April 2024.
>>
>>
>> 6. OWL (architecture/owl.cpp)
>>
>> Script: faust2owl
>>
>> Targets the Rebel Technology OWL platform. Notable because it already
>> implements a custom OwlMemoryManager (using the Faust -mem memory manager
>> API), making it one of the few embedded architectures that leverages the
>> custom memory allocation infrastructure. Single file architecture.
>>
>>
>> 7. CHAOS STRATUS (architecture/chaos-stratus/)
>>
>> Script: faust2stratus
>>
>> Targets the Chaos Audio Stratus guitar pedal. Uses a Linux-based embedded
>> system with SSH/SCP deployment. Architecture includes build scripts, Docker
>> support for cross-compilation, and a stratus.cpp file. Relatively
>> sophisticated deployment pipeline.
>>
>>
>> 8. SAM (architecture/sam/)
>>
>> An older, apparently less-maintained architecture (last commit from 2019).
>>
>>
>> CROSS-CUTTING INFRASTRUCTURE ALREADY AVAILABLE
>> ===============================================
>>
>> The Faust compiler already provides several features that are relevant to
>> embedded targets but are NOT uniformly exploited across all embedded
>> architectures:
>>
>> The -mem / --memory-manager option: Generates code where large arrays
>> become pointers allocated via an external dsp_memory_manager. This enables
>> distributing DSP memory across SRAM/SDRAM/DTCM. The memoryInfo() method
>> provides detailed information about each zone's size and read/write access
>> patterns. Currently only the OWL architecture actually uses this. The Daisy
>> architecture works around the same problem with a Python post-processing
>> script instead.
>>
>> The -uim option: Generates static C preprocessor macros
>> (FAUST_ADDHORIZONTALSLIDER, FAUST_LIST_ACTIVES, etc.) that describe control
>> parameters without requiring the full UI class hierarchy. This is ideal for
>> embedded platforms where you don't need a graphical UI and want to avoid
>> the overhead of buildUserInterface and its metadata tables. Demonstrated in
>> minimal-static.cpp but not used by any current embedded architecture.
>>
>> The -inpl (in-place) option: Generates code where input and output
>> buffers can be the same memory -- noted in the docs as being "typically
>> needed in some embedded devices." Only works in scalar mode.
>>
>> The C backend (-lang c): Can generate pure C code instead of C++,
>> avoiding C++ runtime overhead (vtables, exceptions, RTTI, stdio, etc.).
>> Uses CGlue.h and CInterface.h. Not currently used by any embedded
>> architecture.
>>
>> Metadata conventions: A common set of [switch:N], [knob:N] metadata has
>> been defined for devices without screens. The Hothouse extends this with
>> [toggle:N] and [foot:N]. The documentation notes that this set "will
>> probably have to be progressively defined and standardized."
>>
>> JSON memory layout: When using -mem -json, the complete memory layout is
>> emitted in JSON, allowing compile-time memory planning (e.g., using #pragma
>> directives for memory segments). This enables hybrid static/dynamic memory
>> management.
>>
>>
>> GAPS AND OPPORTUNITIES (What Stephane Is Calling For)
>> =====================================================
>>
>> Based on this survey, the key gaps that new "embedded hardware aware"
>> architecture files could address:
>>
>> UI overhead problem: The Teensy thread exposed this directly -- the
>> standard buildUserInterface / setParamValue / string-matching metadata
>> table approach creates significant memory and code overhead. The -uim
>> option already generates lightweight C macros as an alternative, but no
>> embedded architecture currently uses it.
>>
>> No uniform memory management: Each platform handles memory constraints
>> differently -- Daisy uses a Python post-processor, OWL uses -mem with a
>> custom allocator, Teensy has no solution at all. A unified approach using
>> -mem with platform-specific allocators would be cleaner.
>>
>> C++ library bloat: As Stephane noted, even using stdio can produce huge
>> binaries. The C backend (-lang c) could help, but there are no architecture
>> files that use it for embedded targets. Raw C output combined with -uim
>> macros could produce dramatically smaller binaries.
>>
>> Inconsistent feature support: The Daisy architecture is the most complete
>> (SDRAM support, multiple board variants, flash modes, active refactoring),
>> while Teensy hasn't been touched in over 3 years. No embedded architecture
>> supports the -mem option uniformly.
>>
>> No Pico DSP architecture: Despite being mentioned in the Faust
>> documentation's embedded platforms section, there is no faust2pico or Pico
>> architecture directory.
>>
>> Limited documentation: Only Teensy and ESP32 have tutorials on the Faust
>> documentation site. No Daisy tutorial exists despite it being the most
>> actively developed embedded target.
>>
>>
>> _______________________________________________
>> Faudiostream-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>> _______________________________________________
>> Faudiostream-users mailing list
>> Fau...@li...
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>

[Faudiostream-users] New: Raspberry PI 5 (or 4B) for Faust

[Joachim K. <kr...@po...>]

Hello, great folks!

I am in the learncurve, steeper parts.
I managed to get Faust code in the online editor and it sounds good on a PC 
(stereo), sounds bad on a powerful Android (Samsung S22 ultra).
I also managed to have a working 7.1 (8 channel sound files) USB soundcard 
on a Raspberry PI 4B and ALSA.
This is my target hardware.
I pulled from the recent conversation, that I should move to jack libraries 
in order to have a chance to have reliable output port numbering and a 
working microphone input.
I think about some more microphones and hope to connect them via USB, too.
I have no clue, if this is easy to change, going from alsa to jack. I hope so.

I intend to process midi as adjustment parameters, a midi keyboard with 
dials for settings.
Most important, the sound shall be moved in the room and I learned, there 
is also an interface to osc library thru messages to the ports, where osc 
is listening. The unit shall be controlled via http service, for some 
settings, too.
The Raspberry shall run all of this. I have in mind, to use a PI 5 with SSD 
drive.

My very first questions are focused to faust dsp on the PI.and difference 
between jach and ALSA. I did not try faust to run on the PI so far!
Can you propose steps to configure my system?
The CMedia chipset seems to have broad support. It is heart of my tested 
adapters.
Sound quality is not critical, but fluent, reliable work and: cost 
effective solution is a must.
Any tips are welcome!

Greetings from Hamburg
Joachim

Tel. +49 (0)171 822 4624



Am 5. März 2026 22:26:00 schrieb Tejas Rode <tej...@gm...>:
> Great conversation and inputs!

Re: [Faudiostream-users] Question about creating a triangle wave

[Tejas R. <tej...@gm...>]

Great conversation and inputs!

Tommy, is the -uim flag implicitly used when I click on the 'truck' icon
and select 'teensy' in fausteditor online? If not, how could I enable it?
Since I'm new to faust, I'll need some direction there.

If, in the end, the upper limit on the number of instances of
alias-suppressed triangle acts as a roadblock, I'll have to unfortunately
move away from faust, and rely on what native teensy functions can do.

Thanks,
Tejas

On Thu, Mar 5, 2026 at 10:22 AM Tommy Rushton <tom...@gm...>
wrote:

> The -uim option already generates lightweight C macros as an alternative,
> but no embedded architecture currently uses it.
>
> On the contrary, faust2teensy uses this flag...
>
> if [ $LIB -eq 1 ]; then    mkdir -p $MODULENAME
>     faust $OPTIONS -uim -a $FAUSTARCH/teensy/teensy.cpp -i $FILE -o $MODULENAME/$MODULENAME.cpp
>
> etc.
>
> Cheers,
>
> Tommy
>
>
> Le 05/03/2026 à 16:28, Julius Smith a écrit :
>
> > Can Gemini help ((-: ?
>
> Absolutely!  However, for software development, I prefer Claude Opus 4.6
> (with "thinking" enabled liberally).  Here is Claude's first take:
>
> Prompt:
> > Research existing Faust architecture files for embedded targets to
> understand what currently exists
>
> Reply:
> Here is an overview of existing Faust architecture files for embedded
> platforms, compiled by browsing the Faust GitHub repo and documentation
> site.
>
> OVERVIEW OF EXISTING FAUST ARCHITECTURE FILES FOR EMBEDDED PROCESSORS
> =====================================================================
>
> THE CURRENT LANDSCAPE
>
> Faust currently targets seven embedded/microcontroller platforms through
> dedicated architecture files and faust2xx scripts. Each has its own
> directory under architecture/ in the Faust repo, plus a corresponding
> faust2xx script in tools/faust2appls/. Here is what exists:
>
>
> 1. TEENSY (architecture/teensy/)
>
> Files: teensy.cpp, teensy.h, README
> Last updated: Nov 2023 (3 years ago)
> Script: faust2teensy [-lib] [-midi] [-nvoices <num>]
>
> Generates objects compatible with the PJRC Teensy Audio Library. The
> generated C++ class derives from AudioStream and uses setParamValue with
> string-matching metadata tables to expose hslider/nentry/vslider controls.
> Supports Teensy 3.6 and 4.x (FPU required). Has a tutorial on the Faust
> documentation site. Key limitations (as exposed in this email thread): the
> UI metadata/control structure (string-matching table for setParamValue)
> creates substantial overhead, limiting the number of instances that can run
> concurrently. No -mem or -sdram option support.
>
>
> 2. DAISY (architecture/daisy/)
>
> Files: ex_faust.cpp, Makefile, faust_daisy_mem.py, README
> Last updated: Dec 2025 (3 months ago, actively maintained)
> Script: faust2daisy [-patch] [-pod] [-patchsm] [-sdram] [-mem-thresh
> <num>] [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>] [-sram] [-qspi]
>
> Supports Electrosmith Daisy Seed, Pod, Patch, and Patch.Init() boards. Has
> the most sophisticated embedded memory handling: a Python script
> (faust_daisy_mem.py) post-processes generated C++ to move large buffers to
> SDRAM. Supports multiple flash modes (FLASH, SRAM, QSPI). Uses custom
> DaisyControlUI.h and daisy-midi.h headers. The README notes an active
> refactoring underway, with planned features including more compact code,
> static memory allocation, and MIDI polyphonic support. No tutorial on the
> Faust documentation site.
>
>
> 3. ESP32 (architecture/esp32/)
>
> Script: faust2esp32 [-lib] [-gramophone] [-multi] [-midi] [-nvoices <num>]
> [-wm8978 or -ac101]
>
> Targets the Espressif ESP32 family. Generates a C++ class and audio codec
> configuration objects. Currently supports the Wolfson WM8978 (TTGO T-Audio)
> and AC101 codecs. Has a dedicated GRAME "Gramophone" mode. Has a tutorial
> on the Faust documentation site. Includes a drivers/ folder with
> codec-specific documentation.
>
>
> 4. HOTHOUSE (architecture/hothouse/)
>
> Script: faust2hothouse [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>]
>
> Targets the Cleveland Music Co. Hothouse DIY Pedal (Daisy-based). Supports
> 6 knobs, 3 toggle switches, and 2 foot switches via [knob:N], [toggle:N],
> [foot:N] metadata. Uses a Python script for SDRAM placement of large
> buffers (same approach as Daisy). Uses custom HothouseControlUI.h and
> shares daisy-midi.h with the Daisy architecture. Relatively recent addition.
>
>
> 5. BELA (architecture/bela.cpp)
>
> Script: faust2bela
>
> A single architecture file for the Bela platform (BeagleBone Black-based).
> Bela is more of an embedded Linux system than a bare-metal microcontroller,
> so it has more resources available. Architecture file was last touched in
> April 2024.
>
>
> 6. OWL (architecture/owl.cpp)
>
> Script: faust2owl
>
> Targets the Rebel Technology OWL platform. Notable because it already
> implements a custom OwlMemoryManager (using the Faust -mem memory manager
> API), making it one of the few embedded architectures that leverages the
> custom memory allocation infrastructure. Single file architecture.
>
>
> 7. CHAOS STRATUS (architecture/chaos-stratus/)
>
> Script: faust2stratus
>
> Targets the Chaos Audio Stratus guitar pedal. Uses a Linux-based embedded
> system with SSH/SCP deployment. Architecture includes build scripts, Docker
> support for cross-compilation, and a stratus.cpp file. Relatively
> sophisticated deployment pipeline.
>
>
> 8. SAM (architecture/sam/)
>
> An older, apparently less-maintained architecture (last commit from 2019).
>
>
> CROSS-CUTTING INFRASTRUCTURE ALREADY AVAILABLE
> ===============================================
>
> The Faust compiler already provides several features that are relevant to
> embedded targets but are NOT uniformly exploited across all embedded
> architectures:
>
> The -mem / --memory-manager option: Generates code where large arrays
> become pointers allocated via an external dsp_memory_manager. This enables
> distributing DSP memory across SRAM/SDRAM/DTCM. The memoryInfo() method
> provides detailed information about each zone's size and read/write access
> patterns. Currently only the OWL architecture actually uses this. The Daisy
> architecture works around the same problem with a Python post-processing
> script instead.
>
> The -uim option: Generates static C preprocessor macros
> (FAUST_ADDHORIZONTALSLIDER, FAUST_LIST_ACTIVES, etc.) that describe control
> parameters without requiring the full UI class hierarchy. This is ideal for
> embedded platforms where you don't need a graphical UI and want to avoid
> the overhead of buildUserInterface and its metadata tables. Demonstrated in
> minimal-static.cpp but not used by any current embedded architecture.
>
> The -inpl (in-place) option: Generates code where input and output buffers
> can be the same memory -- noted in the docs as being "typically needed in
> some embedded devices." Only works in scalar mode.
>
> The C backend (-lang c): Can generate pure C code instead of C++, avoiding
> C++ runtime overhead (vtables, exceptions, RTTI, stdio, etc.). Uses CGlue.h
> and CInterface.h. Not currently used by any embedded architecture.
>
> Metadata conventions: A common set of [switch:N], [knob:N] metadata has
> been defined for devices without screens. The Hothouse extends this with
> [toggle:N] and [foot:N]. The documentation notes that this set "will
> probably have to be progressively defined and standardized."
>
> JSON memory layout: When using -mem -json, the complete memory layout is
> emitted in JSON, allowing compile-time memory planning (e.g., using #pragma
> directives for memory segments). This enables hybrid static/dynamic memory
> management.
>
>
> GAPS AND OPPORTUNITIES (What Stephane Is Calling For)
> =====================================================
>
> Based on this survey, the key gaps that new "embedded hardware aware"
> architecture files could address:
>
> UI overhead problem: The Teensy thread exposed this directly -- the
> standard buildUserInterface / setParamValue / string-matching metadata
> table approach creates significant memory and code overhead. The -uim
> option already generates lightweight C macros as an alternative, but no
> embedded architecture currently uses it.
>
> No uniform memory management: Each platform handles memory constraints
> differently -- Daisy uses a Python post-processor, OWL uses -mem with a
> custom allocator, Teensy has no solution at all. A unified approach using
> -mem with platform-specific allocators would be cleaner.
>
> C++ library bloat: As Stephane noted, even using stdio can produce huge
> binaries. The C backend (-lang c) could help, but there are no architecture
> files that use it for embedded targets. Raw C output combined with -uim
> macros could produce dramatically smaller binaries.
>
> Inconsistent feature support: The Daisy architecture is the most complete
> (SDRAM support, multiple board variants, flash modes, active refactoring),
> while Teensy hasn't been touched in over 3 years. No embedded architecture
> supports the -mem option uniformly.
>
> No Pico DSP architecture: Despite being mentioned in the Faust
> documentation's embedded platforms section, there is no faust2pico or Pico
> architecture directory.
>
> Limited documentation: Only Teensy and ESP32 have tutorials on the Faust
> documentation site. No Daisy tutorial exists despite it being the most
> actively developed embedded target.
>
>
> _______________________________________________
> Faudiostream-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>

Re: [Faudiostream-users] Question about creating a triangle wave

[Tommy R. <tom...@gm...>]

> The -uim option already generates lightweight C macros as an 
> alternative, but no embedded architecture currently uses it.
On the contrary, faust2teensy uses this flag...

if [ $LIB -eq1 ];then mkdir -p $MODULENAME
     faust $OPTIONS -uim -a $FAUSTARCH/teensy/teensy.cpp -i $FILE -o $MODULENAME/$MODULENAME.cpp

etc.

Cheers,

Tommy


Le 05/03/2026 à 16:28, Julius Smith a écrit :
> > Can Gemini help ((-: ?
>
> Absolutely!  However, for software development, I prefer Claude Opus 
> 4.6 (with "thinking" enabled liberally). Here is Claude's first take:
>
> Prompt:
> > Research existing Faust architecture files for embedded targets to 
> understand what currently exists
>
> Reply:
> Here is an overview of existing Faust architecture files for embedded 
> platforms, compiled by browsing the Faust GitHub repo and 
> documentation site.
>
> OVERVIEW OF EXISTING FAUST ARCHITECTURE FILES FOR EMBEDDED PROCESSORS
> =====================================================================
>
> THE CURRENT LANDSCAPE
>
> Faust currently targets seven embedded/microcontroller platforms 
> through dedicated architecture files and faust2xx scripts. Each has 
> its own directory under architecture/ in the Faust repo, plus a 
> corresponding faust2xx script in tools/faust2appls/. Here is what exists:
>
>
> 1. TEENSY (architecture/teensy/)
>
> Files: teensy.cpp, teensy.h, README
> Last updated: Nov 2023 (3 years ago)
> Script: faust2teensy [-lib] [-midi] [-nvoices <num>]
>
> Generates objects compatible with the PJRC Teensy Audio Library. The 
> generated C++ class derives from AudioStream and uses setParamValue 
> with string-matching metadata tables to expose hslider/nentry/vslider 
> controls. Supports Teensy 3.6 and 4.x (FPU required). Has a tutorial 
> on the Faust documentation site. Key limitations (as exposed in this 
> email thread): the UI metadata/control structure (string-matching 
> table for setParamValue) creates substantial overhead, limiting the 
> number of instances that can run concurrently. No -mem or -sdram 
> option support.
>
>
> 2. DAISY (architecture/daisy/)
>
> Files: ex_faust.cpp, Makefile, faust_daisy_mem.py, README
> Last updated: Dec 2025 (3 months ago, actively maintained)
> Script: faust2daisy [-patch] [-pod] [-patchsm] [-sdram] [-mem-thresh 
> <num>] [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>] [-sram] [-qspi]
>
> Supports Electrosmith Daisy Seed, Pod, Patch, and Patch.Init() boards. 
> Has the most sophisticated embedded memory handling: a Python script 
> (faust_daisy_mem.py) post-processes generated C++ to move large 
> buffers to SDRAM. Supports multiple flash modes (FLASH, SRAM, QSPI). 
> Uses custom DaisyControlUI.h and daisy-midi.h headers. The README 
> notes an active refactoring underway, with planned features including 
> more compact code, static memory allocation, and MIDI polyphonic 
> support. No tutorial on the Faust documentation site.
>
>
> 3. ESP32 (architecture/esp32/)
>
> Script: faust2esp32 [-lib] [-gramophone] [-multi] [-midi] [-nvoices 
> <num>] [-wm8978 or -ac101]
>
> Targets the Espressif ESP32 family. Generates a C++ class and audio 
> codec configuration objects. Currently supports the Wolfson WM8978 
> (TTGO T-Audio) and AC101 codecs. Has a dedicated GRAME "Gramophone" 
> mode. Has a tutorial on the Faust documentation site. Includes a 
> drivers/ folder with codec-specific documentation.
>
>
> 4. HOTHOUSE (architecture/hothouse/)
>
> Script: faust2hothouse [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>]
>
> Targets the Cleveland Music Co. Hothouse DIY Pedal (Daisy-based). 
> Supports 6 knobs, 3 toggle switches, and 2 foot switches via [knob:N], 
> [toggle:N], [foot:N] metadata. Uses a Python script for SDRAM 
> placement of large buffers (same approach as Daisy). Uses custom 
> HothouseControlUI.h and shares daisy-midi.h with the Daisy 
> architecture. Relatively recent addition.
>
>
> 5. BELA (architecture/bela.cpp)
>
> Script: faust2bela
>
> A single architecture file for the Bela platform (BeagleBone 
> Black-based). Bela is more of an embedded Linux system than a 
> bare-metal microcontroller, so it has more resources available. 
> Architecture file was last touched in April 2024.
>
>
> 6. OWL (architecture/owl.cpp)
>
> Script: faust2owl
>
> Targets the Rebel Technology OWL platform. Notable because it already 
> implements a custom OwlMemoryManager (using the Faust -mem memory 
> manager API), making it one of the few embedded architectures that 
> leverages the custom memory allocation infrastructure. Single file 
> architecture.
>
>
> 7. CHAOS STRATUS (architecture/chaos-stratus/)
>
> Script: faust2stratus
>
> Targets the Chaos Audio Stratus guitar pedal. Uses a Linux-based 
> embedded system with SSH/SCP deployment. Architecture includes build 
> scripts, Docker support for cross-compilation, and a stratus.cpp file. 
> Relatively sophisticated deployment pipeline.
>
>
> 8. SAM (architecture/sam/)
>
> An older, apparently less-maintained architecture (last commit from 2019).
>
>
> CROSS-CUTTING INFRASTRUCTURE ALREADY AVAILABLE
> ===============================================
>
> The Faust compiler already provides several features that are relevant 
> to embedded targets but are NOT uniformly exploited across all 
> embedded architectures:
>
> The -mem / --memory-manager option: Generates code where large arrays 
> become pointers allocated via an external dsp_memory_manager. This 
> enables distributing DSP memory across SRAM/SDRAM/DTCM. The 
> memoryInfo() method provides detailed information about each zone's 
> size and read/write access patterns. Currently only the OWL 
> architecture actually uses this. The Daisy architecture works around 
> the same problem with a Python post-processing script instead.
>
> The -uim option: Generates static C preprocessor macros 
> (FAUST_ADDHORIZONTALSLIDER, FAUST_LIST_ACTIVES, etc.) that describe 
> control parameters without requiring the full UI class hierarchy. This 
> is ideal for embedded platforms where you don't need a graphical UI 
> and want to avoid the overhead of buildUserInterface and its metadata 
> tables. Demonstrated in minimal-static.cpp but not used by any current 
> embedded architecture.
>
> The -inpl (in-place) option: Generates code where input and output 
> buffers can be the same memory -- noted in the docs as being 
> "typically needed in some embedded devices." Only works in scalar mode.
>
> The C backend (-lang c): Can generate pure C code instead of C++, 
> avoiding C++ runtime overhead (vtables, exceptions, RTTI, stdio, 
> etc.). Uses CGlue.h and CInterface.h. Not currently used by any 
> embedded architecture.
>
> Metadata conventions: A common set of [switch:N], [knob:N] metadata 
> has been defined for devices without screens. The Hothouse extends 
> this with [toggle:N] and [foot:N]. The documentation notes that this 
> set "will probably have to be progressively defined and standardized."
>
> JSON memory layout: When using -mem -json, the complete memory layout 
> is emitted in JSON, allowing compile-time memory planning (e.g., using 
> #pragma directives for memory segments). This enables hybrid 
> static/dynamic memory management.
>
>
> GAPS AND OPPORTUNITIES (What Stephane Is Calling For)
> =====================================================
>
> Based on this survey, the key gaps that new "embedded hardware aware" 
> architecture files could address:
>
> UI overhead problem: The Teensy thread exposed this directly -- the 
> standard buildUserInterface / setParamValue / string-matching metadata 
> table approach creates significant memory and code overhead. The -uim 
> option already generates lightweight C macros as an alternative, but 
> no embedded architecture currently uses it.
>
> No uniform memory management: Each platform handles memory constraints 
> differently -- Daisy uses a Python post-processor, OWL uses -mem with 
> a custom allocator, Teensy has no solution at all. A unified approach 
> using -mem with platform-specific allocators would be cleaner.
>
> C++ library bloat: As Stephane noted, even using stdio can produce 
> huge binaries. The C backend (-lang c) could help, but there are no 
> architecture files that use it for embedded targets. Raw C output 
> combined with -uim macros could produce dramatically smaller binaries.
>
> Inconsistent feature support: The Daisy architecture is the most 
> complete (SDRAM support, multiple board variants, flash modes, active 
> refactoring), while Teensy hasn't been touched in over 3 years. No 
> embedded architecture supports the -mem option uniformly.
>
> No Pico DSP architecture: Despite being mentioned in the Faust 
> documentation's embedded platforms section, there is no faust2pico or 
> Pico architecture directory.
>
> Limited documentation: Only Teensy and ESP32 have tutorials on the 
> Faust documentation site. No Daisy tutorial exists despite it being 
> the most actively developed embedded target.
>
>
> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Question about creating a triangle wave

[Julius S. <jul...@gm...>]

> Can Gemini help ((-: ?

Absolutely!  However, for software development, I prefer Claude Opus 4.6
(with "thinking" enabled liberally).  Here is Claude's first take:

Prompt:
> Research existing Faust architecture files for embedded targets to
understand what currently exists

Reply:
Here is an overview of existing Faust architecture files for embedded
platforms, compiled by browsing the Faust GitHub repo and documentation
site.

OVERVIEW OF EXISTING FAUST ARCHITECTURE FILES FOR EMBEDDED PROCESSORS
=====================================================================

THE CURRENT LANDSCAPE

Faust currently targets seven embedded/microcontroller platforms through
dedicated architecture files and faust2xx scripts. Each has its own
directory under architecture/ in the Faust repo, plus a corresponding
faust2xx script in tools/faust2appls/. Here is what exists:


1. TEENSY (architecture/teensy/)

Files: teensy.cpp, teensy.h, README
Last updated: Nov 2023 (3 years ago)
Script: faust2teensy [-lib] [-midi] [-nvoices <num>]

Generates objects compatible with the PJRC Teensy Audio Library. The
generated C++ class derives from AudioStream and uses setParamValue with
string-matching metadata tables to expose hslider/nentry/vslider controls.
Supports Teensy 3.6 and 4.x (FPU required). Has a tutorial on the Faust
documentation site. Key limitations (as exposed in this email thread): the
UI metadata/control structure (string-matching table for setParamValue)
creates substantial overhead, limiting the number of instances that can run
concurrently. No -mem or -sdram option support.


2. DAISY (architecture/daisy/)

Files: ex_faust.cpp, Makefile, faust_daisy_mem.py, README
Last updated: Dec 2025 (3 months ago, actively maintained)
Script: faust2daisy [-patch] [-pod] [-patchsm] [-sdram] [-mem-thresh <num>]
[-midi] [-nvoices <num>] [-sr <num>] [-bs <num>] [-sram] [-qspi]

Supports Electrosmith Daisy Seed, Pod, Patch, and Patch.Init() boards. Has
the most sophisticated embedded memory handling: a Python script
(faust_daisy_mem.py) post-processes generated C++ to move large buffers to
SDRAM. Supports multiple flash modes (FLASH, SRAM, QSPI). Uses custom
DaisyControlUI.h and daisy-midi.h headers. The README notes an active
refactoring underway, with planned features including more compact code,
static memory allocation, and MIDI polyphonic support. No tutorial on the
Faust documentation site.


3. ESP32 (architecture/esp32/)

Script: faust2esp32 [-lib] [-gramophone] [-multi] [-midi] [-nvoices <num>]
[-wm8978 or -ac101]

Targets the Espressif ESP32 family. Generates a C++ class and audio codec
configuration objects. Currently supports the Wolfson WM8978 (TTGO T-Audio)
and AC101 codecs. Has a dedicated GRAME "Gramophone" mode. Has a tutorial
on the Faust documentation site. Includes a drivers/ folder with
codec-specific documentation.


4. HOTHOUSE (architecture/hothouse/)

Script: faust2hothouse [-midi] [-nvoices <num>] [-sr <num>] [-bs <num>]

Targets the Cleveland Music Co. Hothouse DIY Pedal (Daisy-based). Supports
6 knobs, 3 toggle switches, and 2 foot switches via [knob:N], [toggle:N],
[foot:N] metadata. Uses a Python script for SDRAM placement of large
buffers (same approach as Daisy). Uses custom HothouseControlUI.h and
shares daisy-midi.h with the Daisy architecture. Relatively recent addition.


5. BELA (architecture/bela.cpp)

Script: faust2bela

A single architecture file for the Bela platform (BeagleBone Black-based).
Bela is more of an embedded Linux system than a bare-metal microcontroller,
so it has more resources available. Architecture file was last touched in
April 2024.


6. OWL (architecture/owl.cpp)

Script: faust2owl

Targets the Rebel Technology OWL platform. Notable because it already
implements a custom OwlMemoryManager (using the Faust -mem memory manager
API), making it one of the few embedded architectures that leverages the
custom memory allocation infrastructure. Single file architecture.


7. CHAOS STRATUS (architecture/chaos-stratus/)

Script: faust2stratus

Targets the Chaos Audio Stratus guitar pedal. Uses a Linux-based embedded
system with SSH/SCP deployment. Architecture includes build scripts, Docker
support for cross-compilation, and a stratus.cpp file. Relatively
sophisticated deployment pipeline.


8. SAM (architecture/sam/)

An older, apparently less-maintained architecture (last commit from 2019).


CROSS-CUTTING INFRASTRUCTURE ALREADY AVAILABLE
===============================================

The Faust compiler already provides several features that are relevant to
embedded targets but are NOT uniformly exploited across all embedded
architectures:

The -mem / --memory-manager option: Generates code where large arrays
become pointers allocated via an external dsp_memory_manager. This enables
distributing DSP memory across SRAM/SDRAM/DTCM. The memoryInfo() method
provides detailed information about each zone's size and read/write access
patterns. Currently only the OWL architecture actually uses this. The Daisy
architecture works around the same problem with a Python post-processing
script instead.

The -uim option: Generates static C preprocessor macros
(FAUST_ADDHORIZONTALSLIDER, FAUST_LIST_ACTIVES, etc.) that describe control
parameters without requiring the full UI class hierarchy. This is ideal for
embedded platforms where you don't need a graphical UI and want to avoid
the overhead of buildUserInterface and its metadata tables. Demonstrated in
minimal-static.cpp but not used by any current embedded architecture.

The -inpl (in-place) option: Generates code where input and output buffers
can be the same memory -- noted in the docs as being "typically needed in
some embedded devices." Only works in scalar mode.

The C backend (-lang c): Can generate pure C code instead of C++, avoiding
C++ runtime overhead (vtables, exceptions, RTTI, stdio, etc.). Uses CGlue.h
and CInterface.h. Not currently used by any embedded architecture.

Metadata conventions: A common set of [switch:N], [knob:N] metadata has
been defined for devices without screens. The Hothouse extends this with
[toggle:N] and [foot:N]. The documentation notes that this set "will
probably have to be progressively defined and standardized."

JSON memory layout: When using -mem -json, the complete memory layout is
emitted in JSON, allowing compile-time memory planning (e.g., using #pragma
directives for memory segments). This enables hybrid static/dynamic memory
management.


GAPS AND OPPORTUNITIES (What Stephane Is Calling For)
=====================================================

Based on this survey, the key gaps that new "embedded hardware aware"
architecture files could address:

UI overhead problem: The Teensy thread exposed this directly -- the
standard buildUserInterface / setParamValue / string-matching metadata
table approach creates significant memory and code overhead. The -uim
option already generates lightweight C macros as an alternative, but no
embedded architecture currently uses it.

No uniform memory management: Each platform handles memory constraints
differently -- Daisy uses a Python post-processor, OWL uses -mem with a
custom allocator, Teensy has no solution at all. A unified approach using
-mem with platform-specific allocators would be cleaner.

C++ library bloat: As Stephane noted, even using stdio can produce huge
binaries. The C backend (-lang c) could help, but there are no architecture
files that use it for embedded targets. Raw C output combined with -uim
macros could produce dramatically smaller binaries.

Inconsistent feature support: The Daisy architecture is the most complete
(SDRAM support, multiple board variants, flash modes, active refactoring),
while Teensy hasn't been touched in over 3 years. No embedded architecture
supports the -mem option uniformly.

No Pico DSP architecture: Despite being mentioned in the Faust
documentation's embedded platforms section, there is no faust2pico or Pico
architecture directory.

Limited documentation: Only Teensy and ESP32 have tutorials on the Faust
documentation site. No Daisy tutorial exists despite it being the most
actively developed embedded target.

[Faudiostream-users] LAC 2026 - deadline extension

[Victor L. <Vic...@mu...>]

The LAC 2026 deadline for submissions has been extended to 18/03.
All welcome to participate, check it out

Conference site: https://lac26.mucs.club <https://lac26.mucs.club/>
submissions: https://lac2026.sciencesconf.org/

best regards
========================
Prof. Victor Lazzarini
Maynooth University
Ireland






The information contained in this email may be confidential and privileged. It is intended only for the addressee(s) stated above. If you are not an addressee any use, dissemination, distribution, publication or copying of the information contained in this email is strictly prohibited. If you have received this email in error, please immediately notify us by email at dat...@mu...<mailto:dat...@mu...> and delete this email from your system.

Please note that Maynooth University is subject to Freedom of Information and Data Protection laws. We may be required to disclose the content of emails under the FOI Act 2014, the Data Protection Act 2018 or GDPR.

Is don seolaí / do na seolaithe thuasluaite amháin an ríomhphost seo. D’fhéadfadh an t-eolas atá ann a bheith rúnda agus faoi phribhléid. Mura seolaí tú, tá cosc iomlán ar aon eolas atá sa ríomhphost seo a úsáid, a scaipeadh, a dháileadh, a fhoilsiú nó a chóipeáil. Má fuair tú an ríomhphost seo trí thimpiste, cuir sin in iúl dúinn láithreach trí ríomhphost a chur chuig  dat...@mu...<mailto:dat...@mu...>  agus scrios an ríomhphost seo ó do chóras.

Tabhair faoi deara go bhfuil Ollscoil Mhá Nuad faoi réir dhlíthe um Shaoráil Faisnéise agus um Chosaint Sonraí. D’fhéadfadh ceangal a bheith orainn ábhar ríomhphoist a nochtadh faoin Acht um Shaoráil Faisnéise 2014, faoin Acht um Chosaint Sonraí 2018 nó faoi GDPR.

Registered charity number 20037130

Re: [Faudiostream-users] Question about creating a triangle wave

[Stéphane L. <le...@gr...>]

Hi,

We are aware of this kind of problems on embedded platforms, since issues are similar on the Daisy (https://daisy.audio). The thing is that most of the architecture files have not been designed and implemented with the this kind of memory limitations in mind, and using the C++ libraries (for instance just the «  stdio » one) can produce « huge » binaries »…. 

The proper solution would probably be to rethink all that and have a new set of « embedded hardware aware » architectures files, even possibly using raw C code in some cases.

Can Gemini help ((-: ? 

Stéphane  

> Le 5 mars 2026 à 04:57, Tejas Rode <tej...@gm...> a écrit :
> 
> This time, Gemini’s response sounds a bit more helpful! In the fourth way, it suggests defining the variables as global inputs:
> 
> process(freq, duty, phase) = …;
> 
> Being new to Faust, I’ve not seen this syntax with process. How could I change my Faust code (which I previously shared) to have this format? 
> 
> Thanks,
> Tejas 
> 
> 
> On Wed, Mar 4, 2026 at 5:58 PM Julius Smith <jul...@gm...> wrote:
> More:
> 
> Tejas is correct that the issue is likely tied to how the Teensy Audio Library architecture handles Faust UI elements, rather than raw DSP memory.
> 
> When you use hslider, nentry, or vslider in Faust, the faust2teensy compiler generates specific "metadata" and control structures in the C++ class to make these variables accessible via the setParamValue method. If you have many instances, each with multiple UI elements, you can hit a limit in the way the Teensy Audio Library manages its internal "patch cord" connections or the metadata table size.
> 
> Since you are targeting a Teensy and don't need a graphical interface, here are the ideal ways to initialize and control these variables without using standard UI primitives:
> 
> 1. The "Function Argument" Approach (Best for flexibility)
> Instead of defining freq as a UI element globally, define your triangle wave as a function that takes these values as arguments. You can then "map" these arguments to something that doesn't trigger UI generation.
> 
> Code snippet
> 
> 
> // Instead of: freq = hslider("freq", 440, 20, 20000, 1);
> // Use a function that expects arguments:
> myTriangle(f, d, p) = ... your DSP code using f, d, and p ...;
> 
> // Then instantiate it with specific values or "external" signals
> process = myTriangle(440, 0.5, 0.5);
> 
> 2. Use checkbox for "Invisible" metadata (If you still need setParamValue)
> Sometimes nentry and hslider carry more overhead because they require range checking and step logic. If you only have a few parameters but many instances, you might try using checkbox or a very simple button if the logic allows, but this is usually a stopgap.
> 
> 3. Use arg (C++ Style Arguments)
> If you are comfortable with the generated C++ code, you can use the -args compilation flag with the Faust compiler. This allows you to pass values directly to the DSP's instanceInit function. However, this is less "Faust-native" than the other methods.
> 
> 4. Direct Variable Injection via library
> If you want to keep the variables "tunable" from your .ino sketch without the UI overhead, the most robust way is to define them as global inputs to your process and connect them in the Teensy Audio Tool to a "DC" object or a control signal.
> 	• In Faust: process(f, d, p) = ...; (This creates a 3-input DSP object).
> 	• In Teensy: Use the AudioSynthWaveformDC object to send a constant value into those inputs. This bypasses the Faust UI metadata entirely but keeps the values changeable at runtime.
> Why removing hslider fixed it:
> The Faust Teensy tutorial mentions that setParamValue uses string matching or index matching against a table. Each hslider adds an entry to this table. By switching to constants, you removed the metadata table and the associated string-handling overhead, which is likely where the "upper limit" was being hit.
> 
> Recommendation for Tejas: If you need to change these values at runtime but want to avoid the UI limit, Solution #4 is the most "Teensy-native" way. By defining your freq, duty, and phase as inputs to your process function (e.g., process = myTriangle;), they become standard audio-rate or control-rate inputs in the Teensy Audio System. You can then use the Teensy Audio Library's AudioConnection to plug control values into them.
> 
> 
> On Wed, Mar 4, 2026 at 4:56 PM Julius Smith <jul...@gm...> wrote:
> Gemini replies:
> 
> It appears Tejas has identified a crucial bottleneck: the Teensy Audio Library’s metadata and memory overhead for UI elements.
> 
> When you use hslider, nentry, or vslider in Faust, the compiler generates metadata strings and internal variables to map these to a UI. On a microcontroller like the Teensy, each of these elements consumes a portion of the DMAMEM or RAM used by the Audio Library to manage the "patch cord" system. If you have many instances of a Faust object, ...
> 
> 
> On Tue, Mar 3, 2026 at 8:28 PM Tejas Rode <tej...@gm...> wrote:
> Haha! Thank you for sharing that! :)
> 
> Unfortunately, neither of the recommendations of Gemini worked. What worked, again weirdly, is removing hslider() from the code. When I set freq, duty and phase to constants (namely 440, 0.5 and 0.5), I was able to create innumerable instances of triangle. I think what's coming in the way is not related to Teensy memory at all, but related to Faust's UI, where there's probably an upper limit on the number of UI elements that Faust allows. Since teensy doesn't need UI elements, I removed them from the code. However, I obviously don't want freq, duty and phase to have fixed values. I tried nentry(), but that being a UI element too, has the same problem. What is the ideal way I could initialize the three variables in this case? 
> 
> I'll get to smoothing once this gets fixed. 
> 
> Thanks!
> Tejas
> 
> On Tue, Mar 3, 2026 at 7:29 PM Julius Smith <jul...@gm...> wrote:
> Being obsessed with AI assistance nowadays, I had Gemini answer this one directly in Chrome.  Gemini clearly knows more than me about life on a Teensy, so I delegate that, but the topics I do know about sound correct to me, so consider those "checked by someone who should know presuming he really paid attention" :-).
> 
> Regarding the smoothing making the artifact worse, please post a standalone Faust program that illustrates it as simply as possible.  There's probably a simple problem to fix.  We smoothly use interpolated delay lines all the time.
> 
> --- Begin Gemini Weigh-In ---
> 
> Based on the Faust documentation for Teensy, the issue Tejas is experiencing with the fourth instance of the triangle wave is likely related to RAM (memory) constraints.
> 
> Here is a breakdown of why this is happening and how to address it:
> 
> Why the limit exists
> While the Teensy 4.1 is powerful, it has limited internal RAM. Faust-generated objects, especially those using delay-based oscillators or high-order interpolation (like squareND which Julius suggested), can have a larger memory footprint than expected.
> 	• If your code compiles but fails to execute (e.g., stops at the "Test" print or crashes before setup), it usually means the global objects are exceeding the available DTCM (Data Tightly Coupled Memory), causing the microcontroller to hang during initialization.
> Potential Solutions
> 	• Reduce Table Sizes: If your triangle wave uses a large lookup table, reduce its size. The default Faust oscillators often use a table size of $2^{16}$ (65,536 samples), which is too large for multiple instances on a Teensy. You can try reducing it to $2^{15}$ or $2^{14}$ in your .dsp file:
> Code snippet
> 
> 
> // Example: reducing table size to 32768
> tablesize = 1 << 15; 
> 
> 	• Optimize Delay Lines: Since Tejas mentioned using fdelay, it's important to know that every delay line allocates memory based on its maximum delay length. If you don't specify a maximum, Faust might default to a large value. You can use the -dlt (delay line threshold) compiler option to manage how memory is allocated for these.
> 	• Check Memory Usage: In the Arduino IDE, check the memory report after compilation. If "Global variables use..." is very high (near 100%), adding one more instance will push it over the edge.
> 	• Use AudioMemory: Ensure you have enough audio blocks allocated in your .ino file. While Tejas's snippet doesn't show the AudioMemory() call for the triangle instances, the tutorial recommends increasing this number if you have multiple audio inputs/outputs.
> C++
> 
> 
> void setup() 
> {
>   AudioMemory(
> 12); // Try increasing this value
> 
>   Serial.begin(
> 115200
> );
>   Serial.println(
> "Test"
> );
> }
> 
> For more details on managing memory for Faust on Teensy, you can refer to the Notes About Computational Power and Memory Footprint section of the official tutorial.
> 
> 
> On Tue, Mar 3, 2026 at 4:00 PM Tejas Rode <tej...@gm...> wrote:
> Thank you for the suggestion, Julius! I tried using both fdelay and si.smoo(), but it worsened the artifact. I guess it's because the phase changed more often with those approaches, as compared to using just delay.
> 
> On a different note, I'm trying to run this on teensy 4.1. I've followed this approach: https://faustdoc.grame.fr/tutorials/teensy/ . There is a weird problem, though, where I'm able to create at most three instances of the triangle. If I create a fourth instance, the code compiles, but doesn't do anything. Is there really an upper limit on the number of instances that could be created? How could I change the limit, if any? Here is the code:
> 
> #include <Audio.h>
> #include "FaustTriangle.h"
> FaustTriangle faustTriangle[4];  // "Test" is printed only when the number of instances here are <= 3
> void setup() { 
>   Serial.begin(115200);
>   Serial.println("Test");
> }
> void loop() {}
> 
> Regards,
> Tejas
> 
> On Thu, Feb 26, 2026 at 1:57 AM Julius Smith <jul...@gm...> wrote:
> N is the order of interpolation.  It sounds like you want N=1, but maybe compare to higher N when everything is done.
> 
> Instead of delay, use fdelay, and run its delay parameter through a smoother (e.g., si.smoo(), IIRC)
> 
> On Thu, Feb 26, 2026 at 12:49 AM Tejas Rode <tej...@gm...> wrote:
> Thanks for the hint! This is what I have put together. It runs, but I have further questions.
> 
> import("stdfaust.lib");
> freq = hslider("freq", 440, 11, 880, 1);
> N = 1;  // tried up to 4
> duty = hslider("duty", 0.5, 0, 1, 0.01);
> phase = hslider("phase", 0.5, 0, 1, 0.001);
> triangleND(N,freq,duty,phase) = squareND(N,freq,duty,phase) : fi.pole(p) : *(gain) with {
>   gain = 4.0*freq/ma.SR; 
>   p = 0.999;
> };
> squareND(N,freq,duty,phase) = os.pulsetrainN(N,freq,duty) @ round(phase*ma.SR/freq);  // phase has audible jumps
> process = triangleND(N,freq,duty,phase);
> 
> I have two questions. 
> 1. How does the value of N affect how the output sounds? I tried N=1 to N=4, but didn't hear an audible difference. What value of N should I set as default?
> 2. When I move the phase slider, there are audible jumps. It's probably because the phase is rounding to the nearest integer. Is there a way to make the phase change sound smooth?
> 
> I'm quite new to FAUST. Thank you for all the help!
> 
> Regards,
> Tejas
> 
> On Sun, Feb 22, 2026 at 2:11 AM Julius Smith <jul...@gm...> wrote:
> I think I would just use a delay.  Search for "phase" in oscillators.lib and you'll see various approaches.
> 
> On Sat, Feb 21, 2026 at 9:43 PM Tejas Rode <tej...@gm...> wrote:
> Hi Julius,
> 
> I have a followup question. If I want to add phase value as an argument to this triangleND function, what is the best way to do that? 
> 
> Thanks!
> Tejas
> 
> On Fri, Feb 13, 2026 at 4:08 PM Julius Smith <jul...@gm...> wrote:
> Hi Tejas,
> 
> You might try modifying os.triangleN(N,freq) to add a duty factor, where N is the order of the aliasing suppression.
> It's based on the paper "Alias-Suppressed Oscillators based on Differentiated Polynomial Waveforms" by Valimaki et al.
> 
> My guess:
> 
> triangleND(N,freq,duty) = squareND(N,freq,duty) : fi.pole(p) : *(gain) with {
>   gain = 4.0*freq/ma.SR; // for aproximate unit peak amplitude
>   p = 0.999;
> };
> squareND(N,freq,duty) = pulsetrainN(N,freq,duty);
> 
> Then your 25% case would be os.triangleND(N,freq,0.25);
> 
> Cheers,
> - Julius
> 
> 
> On Fri, Feb 13, 2026 at 10:39 AM Tejas Rode <tej...@gm...> wrote:
> Hello,
> 
> I want to create an anti-aliased dfdsdg triangle wave with 25% duty cycle for use in a teensy project. I'm new to faust. Is there a resource that I can refer to? Any ideas that can help me start implementing this? 
> 
> Thanks,
> Tejas
> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> 
> 
> -- 
> AI has taken my job, but only I know what it is.
> 
> 
> -- 
> AI has taken my job, but only I know what it is.
> 
> 
> -- 
> AI has taken my job, but only I know what it is.
> 
> 
> -- 
> AI has taken my job, but only I know what it is.
> 
> 
> -- 
> AI has taken my job, but only I know what it is.
> 
> 
> -- 
> AI has taken my job, but only I know what it is.
> _______________________________________________
> Faudiostream-users mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Question about creating a triangle wave

[Tejas R. <tej...@gm...>]

This time, Gemini’s response sounds a bit more helpful! In the fourth way,
it suggests defining the variables as global inputs:

process(freq, duty, phase) = …;

Being new to Faust, I’ve not seen this syntax with process. How could I
change my Faust code (which I previously shared) to have this format?

Thanks,
Tejas


On Wed, Mar 4, 2026 at 5:58 PM Julius Smith <jul...@gm...> wrote:

> More:
>
> Tejas is correct that the issue is likely tied to how the *Teensy Audio
> Library* architecture handles Faust UI elements, rather than raw DSP
> memory.
>
> When you use hslider, nentry, or vslider in Faust, the faust2teensy
> compiler generates specific "metadata" and control structures in the C++
> class to make these variables accessible via the setParamValue method. If
> you have many instances, each with multiple UI elements, you can hit a
> limit in the way the Teensy Audio Library manages its internal "patch cord"
> connections or the metadata table size.
>
> Since you are targeting a Teensy and don't need a graphical interface,
> here are the ideal ways to initialize and control these variables without
> using standard UI primitives:
> 1. The "Function Argument" Approach (Best for flexibility)
>
> Instead of defining freq as a UI element globally, define your triangle
> wave as a function that takes these values as arguments. You can then "map"
> these arguments to something that doesn't trigger UI generation.
> Code snippet
>
> // Instead of: freq = hslider("freq", 440, 20, 20000, 1);
> // Use a function that expects arguments:
> myTriangle(f, d, p) = ... your DSP code using f, d, and p ...;
>
> // Then instantiate it with specific values or "external" signals
> process = myTriangle(440, 0.5, 0.5);
>
> 2. Use checkbox for "Invisible" metadata (If you still need setParamValue)
>
> Sometimes nentry and hslider carry more overhead because they require
> range checking and step logic. If you only have a few parameters but many
> instances, you might try using checkbox or a very simple button if the
> logic allows, but this is usually a stopgap.
> 3. Use arg (C++ Style Arguments)
>
> If you are comfortable with the generated C++ code, you can use the -args
> compilation flag with the Faust compiler. This allows you to pass values
> directly to the DSP's instanceInit function. However, this is less
> "Faust-native" than the other methods.
> 4. Direct Variable Injection via library
>
> If you want to keep the variables "tunable" from your .ino sketch without
> the UI overhead, the most robust way is to define them as *global inputs*
> to your process and connect them in the Teensy Audio Tool to a "DC"
> object or a control signal.
>
>    -
>
>    In Faust: process(f, d, p) = ...; (This creates a 3-input DSP object).
>    -
>
>    In Teensy: Use the AudioSynthWaveformDC object to send a constant
>    value into those inputs. This bypasses the Faust UI metadata entirely but
>    keeps the values changeable at runtime.
>
> Why removing hslider fixed it:
>
> The Faust Teensy tutorial <https://faustdoc.grame.fr/tutorials/teensy/>
> mentions that setParamValue uses string matching or index matching
> against a table. Each hslider adds an entry to this table. By switching
> to constants, you removed the metadata table and the associated
> string-handling overhead, which is likely where the "upper limit" was being
> hit.
>
> *Recommendation for Tejas:* If you need to change these values at runtime
> but want to avoid the UI limit, *Solution #4* is the most "Teensy-native"
> way. By defining your freq, duty, and phase as *inputs* to your process
> function (e.g., process = myTriangle;), they become standard audio-rate
> or control-rate inputs in the Teensy Audio System. You can then use the
> Teensy Audio Library's AudioConnection to plug control values into them.
>
> On Wed, Mar 4, 2026 at 4:56 PM Julius Smith <jul...@gm...>
> wrote:
>
>> Gemini replies:
>>
>> It appears Tejas has identified a crucial bottleneck: the *Teensy Audio
>> Library’s metadata and memory overhead for UI elements*.
>>
>> When you use hslider, nentry, or vslider in Faust, the compiler
>> generates metadata strings and internal variables to map these to a UI. On
>> a microcontroller like the Teensy, each of these elements consumes a
>> portion of the *DMAMEM* or *RAM* used by the Audio Library to manage the
>> "patch cord" system. If you have many instances of a Faust object, ...
>>
>> On Tue, Mar 3, 2026 at 8:28 PM Tejas Rode <tej...@gm...> wrote:
>>
>>> Haha! Thank you for sharing that! :)
>>>
>>> Unfortunately, neither of the recommendations of Gemini worked. What
>>> worked, again weirdly, is removing hslider() from the code. When I set
>>> freq, duty and phase to constants (namely 440, 0.5 and 0.5), I was able to
>>> create innumerable instances of triangle. I think what's coming in the way
>>> is not related to Teensy memory at all, but related to Faust's UI, where
>>> there's probably an upper limit on the number of UI elements that Faust
>>> allows. Since teensy doesn't need UI elements, I removed them from the
>>> code. However, I obviously don't want freq, duty and phase to have fixed
>>> values. I tried nentry(), but that being a UI element too, has the same
>>> problem. What is the ideal way I could initialize the three variables in
>>> this case?
>>>
>>> I'll get to smoothing once this gets fixed.
>>>
>>> Thanks!
>>> Tejas
>>>
>>> On Tue, Mar 3, 2026 at 7:29 PM Julius Smith <jul...@gm...>
>>> wrote:
>>>
>>>> Being obsessed with AI assistance nowadays, I had Gemini answer this
>>>> one directly in Chrome.  Gemini clearly knows more than me about life on a
>>>> Teensy, so I delegate that, but the topics I do know about sound correct to
>>>> me, so consider those "checked by someone who should know presuming he
>>>> really paid attention" :-).
>>>>
>>>> Regarding the smoothing making the artifact worse, please post a
>>>> standalone Faust program that illustrates it as simply as possible.
>>>> There's probably a simple problem to fix.  We smoothly use interpolated
>>>> delay lines all the time.
>>>>
>>>> --- Begin Gemini Weigh-In ---
>>>>
>>>> Based on the Faust documentation for Teensy
>>>> <https://faustdoc.grame.fr/tutorials/teensy/>, the issue Tejas is
>>>> experiencing with the fourth instance of the triangle wave is likely
>>>> related to *RAM (memory) constraints*.
>>>>
>>>> Here is a breakdown of why this is happening and how to address it:
>>>> Why the limit exists
>>>>
>>>> While the Teensy 4.1 is powerful, it has limited internal RAM.
>>>> Faust-generated objects, especially those using delay-based oscillators or
>>>> high-order interpolation (like squareND which Julius suggested), can
>>>> have a larger memory footprint than expected.
>>>>
>>>>    -
>>>>
>>>>    If your code compiles but fails to execute (e.g., stops at the
>>>>    "Test" print or crashes before setup), it usually means the global
>>>>    objects are exceeding the available *DTCM (Data Tightly Coupled
>>>>    Memory)*, causing the microcontroller to hang during initialization.
>>>>
>>>> Potential Solutions
>>>>
>>>>    1.
>>>>
>>>>    *Reduce Table Sizes:* If your triangle wave uses a large lookup
>>>>    table, reduce its size. The default Faust oscillators often use a table
>>>>    size of $2^{16}$ (65,536 samples), which is too large for multiple
>>>>    instances on a Teensy. You can try reducing it to $2^{15}$ or
>>>>    $2^{14}$ in your .dsp file:
>>>>    Code snippet
>>>>
>>>>    // Example: reducing table size to 32768
>>>>    tablesize = 1 << 15;
>>>>
>>>>    2.
>>>>
>>>>    *Optimize Delay Lines:* Since Tejas mentioned using fdelay, it's
>>>>    important to know that every delay line allocates memory based on its
>>>>    maximum delay length. If you don't specify a maximum, Faust might default
>>>>    to a large value. You can use the -dlt (delay line threshold)
>>>>    compiler option to manage how memory is allocated for these.
>>>>    3.
>>>>
>>>>    *Check Memory Usage:* In the Arduino IDE, check the memory report
>>>>    after compilation. If "Global variables use..." is very high (near 100%),
>>>>    adding one more instance will push it over the edge.
>>>>    4.
>>>>
>>>>    *Use AudioMemory:* Ensure you have enough audio blocks allocated in
>>>>    your .ino file. While Tejas's snippet doesn't show the AudioMemory()
>>>>    call for the triangle instances, the tutorial recommends increasing this
>>>>    number if you have multiple audio inputs/outputs.
>>>>    C++
>>>>
>>>>    void setup() {
>>>>      AudioMemory(12); // Try increasing this value
>>>>      Serial.begin(115200);
>>>>      Serial.println("Test");
>>>>    }
>>>>
>>>>
>>>> For more details on managing memory for Faust on Teensy, you can refer
>>>> to the *Notes About Computational Power and Memory Footprint
>>>> <https://www.google.com/search?q=https://faustdoc.grame.fr/tutorials/teensy/%23notes-about-computational-power-and-memory-footprint>*
>>>> section of the official tutorial.
>>>>
>>>> On Tue, Mar 3, 2026 at 4:00 PM Tejas Rode <tej...@gm...> wrote:
>>>>
>>>>> Thank you for the suggestion, Julius! I tried using both fdelay and
>>>>> si.smoo(), but it worsened the artifact. I guess it's because the phase
>>>>> changed more often with those approaches, as compared to using just delay.
>>>>>
>>>>> On a different note, I'm trying to run this on teensy 4.1. I've
>>>>> followed this approach: https://faustdoc.grame.fr/tutorials/teensy/ .
>>>>> There is a weird problem, though, where I'm able to create at most three
>>>>> instances of the triangle. If I create a fourth instance, the code
>>>>> compiles, but doesn't do anything. Is there really an upper limit on the
>>>>> number of instances that could be created? How could I change the limit, if
>>>>> any? Here is the code:
>>>>>
>>>>> #include <Audio.h>
>>>>>
>>>>> #include "FaustTriangle.h"
>>>>>
>>>>> FaustTriangle faustTriangle[4];  // "Test" is printed only when the
>>>>> number of instances here are <= 3
>>>>>
>>>>> void setup() {
>>>>>
>>>>>   Serial.begin(115200);
>>>>>
>>>>>   Serial.println("Test");
>>>>>
>>>>> }
>>>>>
>>>>> void loop() {}
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tejas
>>>>>
>>>>> On Thu, Feb 26, 2026 at 1:57 AM Julius Smith <jul...@gm...>
>>>>> wrote:
>>>>>
>>>>>> N is the order of interpolation.  It sounds like you want N=1, but
>>>>>> maybe compare to higher N when everything is done.
>>>>>>
>>>>>> Instead of delay, use fdelay, and run its delay parameter through a
>>>>>> smoother (e.g., si.smoo(), IIRC)
>>>>>>
>>>>>> On Thu, Feb 26, 2026 at 12:49 AM Tejas Rode <tej...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for the hint! This is what I have put together. It runs, but
>>>>>>> I have further questions.
>>>>>>>
>>>>>>> import("stdfaust.lib");
>>>>>>> freq = hslider("freq", 440, 11, 880, 1);
>>>>>>> N = 1;  // tried up to 4
>>>>>>> duty = hslider("duty", 0.5, 0, 1, 0.01);
>>>>>>> phase = hslider("phase", 0.5, 0, 1, 0.001);
>>>>>>> triangleND(N,freq,duty,phase) = squareND(N,freq,duty,phase) :
>>>>>>> fi.pole(p) : *(gain) with {
>>>>>>>   gain = 4.0*freq/ma.SR;
>>>>>>>   p = 0.999;
>>>>>>> };
>>>>>>> squareND(N,freq,duty,phase) = os.pulsetrainN(N,freq,duty) @
>>>>>>> round(phase*ma.SR/freq);  // phase has audible jumps
>>>>>>> process = triangleND(N,freq,duty,phase);
>>>>>>>
>>>>>>> I have two questions.
>>>>>>> 1. How does the value of N affect how the output sounds? I tried N=1
>>>>>>> to N=4, but didn't hear an audible difference. What value of N should I set
>>>>>>> as default?
>>>>>>> 2. When I move the phase slider, there are audible jumps. It's
>>>>>>> probably because the phase is rounding to the nearest integer. Is there a
>>>>>>> way to make the phase change sound smooth?
>>>>>>>
>>>>>>> I'm quite new to FAUST. Thank you for all the help!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Tejas
>>>>>>>
>>>>>>> On Sun, Feb 22, 2026 at 2:11 AM Julius Smith <jul...@gm...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I think I would just use a delay.  Search for "phase" in
>>>>>>>> oscillators.lib and you'll see various approaches.
>>>>>>>>
>>>>>>>> On Sat, Feb 21, 2026 at 9:43 PM Tejas Rode <tej...@gm...>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Julius,
>>>>>>>>>
>>>>>>>>> I have a followup question. If I want to add phase value as an
>>>>>>>>> argument to this triangleND function, what is the best way to do that?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Tejas
>>>>>>>>>
>>>>>>>>> On Fri, Feb 13, 2026 at 4:08 PM Julius Smith <
>>>>>>>>> jul...@gm...> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Tejas,
>>>>>>>>>>
>>>>>>>>>> You might try modifying os.triangleN(N,freq) to add a duty
>>>>>>>>>> factor, where N is the order of the aliasing suppression.
>>>>>>>>>> It's based on the paper "Alias-Suppressed Oscillators based on
>>>>>>>>>> Differentiated Polynomial Waveforms" by Valimaki et al.
>>>>>>>>>>
>>>>>>>>>> My guess:
>>>>>>>>>>
>>>>>>>>>> triangleND(N,freq,duty) = squareND(N,freq,duty) : fi.pole(p) :
>>>>>>>>>> *(gain) with {
>>>>>>>>>>   gain = 4.0*freq/ma.SR; // for aproximate unit peak amplitude
>>>>>>>>>>   p = 0.999;
>>>>>>>>>> };
>>>>>>>>>> squareND(N,freq,duty) = pulsetrainN(N,freq,duty);
>>>>>>>>>>
>>>>>>>>>> Then your 25% case would be os.triangleND(N,freq,0.25);
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> - Julius
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Feb 13, 2026 at 10:39 AM Tejas Rode <tej...@gm...>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> I want to create an anti-aliased dfdsdg triangle wave with 25%
>>>>>>>>>>> duty cycle for use in a teensy project. I'm new to faust. Is there a
>>>>>>>>>>> resource that I can refer to? Any ideas that can help me start implementing
>>>>>>>>>>> this?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Tejas
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Faudiostream-users mailing list
>>>>>>>>>>> Fau...@li...
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> AI has taken my job, but only I know what it is.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> AI has taken my job, but only I know what it is.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> AI has taken my job, but only I know what it is.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> AI has taken my job, but only I know what it is.
>>>>
>>>
>>
>> --
>> AI has taken my job, but only I know what it is.
>>
>
>
> --
> AI has taken my job, but only I know what it is.
>