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