Thanks Tommy! No, I haven’t tried creating triangles in parallel, primarily because all of them are supposed to have different frequencies and other parameters.
Last night, I tried to use Claude to create a .h file in teensy for an alias suppressed triangle whose frequency, duty cycle, phase and amplitude can be set in the teensy loop. Claude did it! The reason I was using faust was that the language is more intuitive as compared to doing the same from scratch in teensy. With tools like Claude, that’s no more a barrier. For now, I’ve paused my efforts in faust. Thanks, Tejas On Sun, Mar 8, 2026 at 8:22 AM Tommy Rushton <[email protected]> wrote: > My Faust program contains 30+ UI elements; I'm not creating 30+ instances > of my Faust program. Now that I think about it, instead of > > FaustTriangle faustTriangle[4]; > > have you tried creating your triangles in parallel in Faust? I.e. > something like > > process = par(i, 4, trinangleND(N, hslider("freq%i", ...), hslider("duty%i", > ...), hslider("phase%i", ...))); > > Tommy > Le 06/03/2026 à 18:44, Tejas Rode a écrit : > > 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
