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
