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
[email protected]
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
_______________________________________________
Faudiostream-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
