Thank you Tommy! Does your teensy use 30+ instances of ONE faust object? Have you tried that? That’s where I’m stuck.
My teensy doesn’t have the extra PSRAM, so I’ll have to work with the default. Also, I’m not yet doing si.smoo, but will avoid that. I don’t think there are large arrays. You can take a look at my faust code from this email thread. Thanks, Tejas On Fri, Mar 6, 2026 at 8:36 AM Tommy Rushton <[email protected]> wrote: > Hi Tejas, > > The faust2[...] tools accept any valid Faust flags as additional > arguments. What I can tell you is, per the script excerpt I shared last > time, faust2teensy does indeed employ the -uim flag implicitly by default > (i.e. specifying it explicitly would be redundant). To answer your > question, yes when you click the truck icon, select teensy as your Platform > and cilck *Compile*, faust2teensy is executed and your code benefits from > application of the -uim flag. > > I've been following this discussion with some curiosity because I work > with the Teensy and have a Faust algorithm with 30+ UI elements that runs > fine. Where I run into problems is with delay lines (due to memory > limitations posed by the Teensy — though experimenting with adding extra > PSRAM has shown promise) and parameter smoothing (I avoid si.smoo and do my > smoothing *outside* of Faust). Does your generated C++ code exhibit any > large arrays? If so, have you experimented with the -dlt flag? > > Cheers, > > Tommy > Le 06/03/2026 à 13:30, Tejas Rode a écrit : > > 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/) >>> >>> 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 >>> [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
