Not sure if it would make a difference to how UI elements use more or less RAM, etc. but OSC and MIDI messages in Faust are strongly-coupled to the *slider elements. It's convenient, but makes me wonder 2 things:
1) if you shouldn't try to see what happens not using a GUI, i.e. declare the UI elements, but compile using something like `faust2jackconsole`, which is all about using pure OSC and MIDI messages without a GUI. 2) if `faust` couldn't use a more low-level primitive set of MIDI functions not so strongly-tied to sliders? As mentioned, the other thing to do would be to simply compile your Faust to C (not C++) and do some manual light-weight cut-n-paste into your project using libraries that don't create a lot of overhead. Faust is great, but the choice of C++, much heavier than C, as a default, isn't the greatest, necessarily. Luckily, there's a way to make Faust compile to C, and I've used it before to excellent effect when the situation calls for it. Aaron Krister Johnson Music, etc.: https://soundcloud.com/aaron-krister-johnson https://soundcloud.com/filtercreed https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg https://aaronkristerjohnson.bandcamp.com/ http://www.untwelve.org Code: https://github.com/akjmicro <http://www.untwelve.org> On Sun, Mar 8, 2026 at 10:35 AM Tejas Rode <[email protected]> wrote: > 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 >
_______________________________________________ Faudiostream-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/faudiostream-users
