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