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