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 -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
