faudiostream-devel — List related to the development of the FAUST language

[Faudiostream-devel] [grame-cncm/faust] Pre-release 2.81.2 - Faust version 2.81.2

[github-actions[bot] <le...@gr...>]

Faust version 2.81.2 <https://github.com/grame-cncm/faust/releases/tag/2.81.2>
Repository: grame-cncm/faust <https://github.com/grame-cncm/faust> · Tag: 2.81.2 <https://github.com/grame-cncm/faust/tree/2.81.2> · Commit: 1316c96 <https://github.com/grame-cncm/faust/commit/1316c964fc01c17fbbd5a77dcc2e3d3f33684d21> · Released by: github-actions[bot] <https://github.com/apps/github-actions>
Change log

WARNING: to get the source version

be sure to download the faust-2.81.2.tar.gz file to get a complete source folder (in particular, with all the libraries).
on macOS, binary files are still to notarise, you may have to use the xattr -rd com.apple.quarantine file command to remove the com.apple.quarantine extended attribute. See the xattr [man page].(https://developer.apple.com/documentation/os/reading_unix_manual_pages <https://developer.apple.com/documentation/os/reading_unix_manual_pages>) for details on how to use that tool. MacOS Monterey is now the minimal version.
New

Add all MCP related code in McpUI.h, put in the faust/gui.
Improve Rust backend for static tables handling.
Add recursion, tables, waveform, select2 and prefix handlling in SignalRenderer.
Add wasmtime architecture.
Rework MidiHandler and audio driver memory handling.
Allow widget modulation targets to be defined by path. For example "chan 3/gain" wiil target any widget "gain" inside a group "chan 3".
WebAssembly mixCheckVoice now use RMS for level computation.
faustgen~: reworked polyphonic handling.
Rework polyphonic handling: VOICE_STOP_LEVEL set to -90 dB, RMS used for level computation, correct legato.
Add pipewire support with console, qt and gtk GUI.
Add kb_rom_rev1.dsp example.
Add RNBO/codebox export in faustgen~ and generateAuxFilesFromFile2/generateAuxFilesFromString2 in libfaust.
Deprecated

Fixed bugs

Fixed sliders that were not being created in MIDI context (skipped), so they now behave as normal sliders controlled manually OR by midi messages, the exception being MIDI controls targetting a specific voice in polyphonic context (not created as sliders). Added program change MIDI support. Added pitchweel MIDI support. Fixed an issue (typo) in ysfx-dsp.h).
JSFXInstVisitor::_midi_poly_assign should only generate polyphonic (freq/gate/gain) parameters.
Incorrect use of integer abs function instead of floating-point std::abs.
Widget Modulation Bug. Labels in format 'v:group1/h:group2/name' were not handled correctly
Libraries

Deterministic noise function.
Add multiTapSincDelay.
Add Vicanek's matched (decramped) second-order Butterworth low and high shelving filters.
Add Vicanek's decramped second-order resonant filters.
—
This release has 11 assets:

Faust-2.81.2-arm64.dmg
Faust-2.81.2-win64.exe
Faust-2.81.2-x64.dmg
faust-2.81.2.tar.gz
faustgen-1.78-arm64.dmg
faustgen-1.78-win64.zip
faustgen-1.78-x64.dmg
libfaust-ubuntu-aarch64.zip
libfaust-ubuntu-x86_64.zip
Source code (zip)
Source code (tar.gz)
Visit the release page <https://github.com/grame-cncm/faust/releases/tag/2.81.2> to download them.

[Faudiostream-devel] Problem compiling with faust2caqt a dsp that embeds WAV files

[Sylvain H. <syl...@gi...>]

Hello,

I am new to faust and encounter two issues while trying to compile a DSP 
that plays WAV files on macOS using the faust2caqt command.
I am using Faust 2.79.3, installed via Homebrew.

1) Linking issue with LAME
I had a linking problem with LAME, which I resolved by manually adding:
Libs.private: -L/opt/homebrew/Cellar/lame/3.100/lib/ -lmp3lame
to:
/opt/homebrew/Cellar/libsndfile/1.2.2_1/lib/pkgconfig/sndfile.pc
However, I have the intuition that this is not a good practice...

2) In my dsp, I specify the paths to the WAV files relatively, but it 
seems that faust2caqt is missing a -p option in a mkdir command executed 
when embedding the WAV file in the .app bundle, below the corrected 
version (it is the last mkdir)

         for snd in $(cat $p-tmp.txt); do
             if [ -f $snd ]; then
                 if [ ${snd:0:1} = "/" ]; then
                     echo "Warning: soundfile with absolute path is not 
copied !"
                 else
                     # create destination path and possibly create directory
sfpath="$TMP/${f%.dsp}$EXT/Contents/Resources/$(dirname $snd)/"
                     if ! [ -d $sfpath ]; then
                         echo "Create $sfpath"
                         mkdir -p $sfpath


FYI, during compilation, I get a lot of error messages like the following.
However, despite these errors, the generated .app is functional.

ERROR: Cannot resolve rpath "@rpath/QtGui.framework/Versions/A/QtGui"
ERROR:  using QList("/hiddenpath/faust/faust.EvpiJ4/mydsp/lib")
ERROR: Cannot resolve rpath "@rpath/QtCore.framework/Versions/A/QtCore"
ERROR:  using QList("/hiddenpath/faust/faust.EvpiJ4/mydsp/lib")

Regards,
Sylvain.

[Faudiostream-devel] Pre-release Faust version 2.79.3

[Stéphane L. <le...@gr...>]

Here: https://github.com/grame-cncm/faust/releases/tag/2.79.3 <https://github.com/grame-cncm/faust/releases/tag/2.79.3>

Feedback welcome.

Stéphane

> 
> Faust version 2.79.3 <https://github.com/grame-cncm/faust/releases/tag/2.79.3>
> Repository: grame-cncm/faust <https://github.com/grame-cncm/faust> · Tag: 2.79.3 <https://github.com/grame-cncm/faust/tree/2.79.3> · Commit: 384f648 <https://github.com/grame-cncm/faust/commit/384f648988c05640a42637cb89e7191e9ad7d6eb> · Released by: github-actions[bot] <https://github.com/apps/github-actions>
> Change log
> 
> WARNING: to get the source version
> 
> be sure to download the faust-2.79.3.tar.gz file to get a complete source folder (in particular, with all the libraries).
> on macOS, binary files are still to notarise, you may have to use the xattr -rd com.apple.quarantine file command to remove the com.apple.quarantine extended attribute. See the xattr [man page].(https://developer.apple.com/documentation/os/reading_unix_manual_pages <https://developer.apple.com/documentation/os/reading_unix_manual_pages>) for details on how to use that tool. MacOS Monterey is now the minimal version.
> New
> 
> faustgen~: more robust code in multichannels mode.
> Add reverbTank.dsp example.
> Add wfs.dsp example.
> Add new mesh2faust API method to generate modal model and Faust DSP code independently.
> Add parameter tracking and FFun/FVar in SDF3 backend.
> SignalPromotion now checks and possibly casts values in the waveform, allowing for simplification in FIR generation.
> Option -rnlm (--rust-no-libm) added in Rust backend.
> Add sflooper.dsp and inlooper.dsp examples.
> Defining sdt::less<CTree*> operator to provide an unique and stable ordering is enough to garanty determinism.
> Add -nopost option to faust2w32max6 and faust2w64max6.
> Install architecture/hothouse folder so that faust2hothouse can use it.
> Deprecated
> 
> Fixed bugs
> 
> Correct rnbo.py for faust2rnbo.
> Add missing parameters in Unity FaustUtilities_template.cs/FaustPolyUtilities_template.cs so JSON parse does not fail.
> faust2atomsnippets now removes the (pf) prefix.
> faust2w32max6 and faust2w64max6 now export DLL that can be correct loaded.
> JUCE: correct setSelectedItemIndex use in uiMenu which should take the value - 1.
> Libraries
> 
> Define generic gen_fb_comb and reimplement fb_comb and fb_fcomb with it.
> Add Keith Barr Allpass Loop Reverb.
> Add WFS algorithm.
> Add os.dsf environment, oscsillators with exponentially decaying harmonics.
> Add pm.rk_solve() function, Runge-Kutta solver.
> Revert to the old CF mapping for the moogLadder filter, add the same filter as a new function that takes parameters in Hz and feedback gain raw values.
> Correct dx.dx7_algo documentation.
> Add svf morph functions.
> David Braun fix on mixLinearClamp/mixLinearLoop/mixPowerClamp/mixPowerLoop to properly accept the N buses as inputs.
> —
> This release has 11 assets:
> 
> Faust-2.79.3-arm64.dmg
> Faust-2.79.3-win64.exe
> Faust-2.79.3-x64.dmg
> faust-2.79.3.tar.gz
> faustgen-1.75-arm64.dmg
> faustgen-1.75-win64.zip
> faustgen-1.75-x64.dmg
> libfaust-ubuntu-aarch64.zip
> libfaust-ubuntu-x86_64.zip
> Source code (zip)
> Source code (tar.gz)
> Visit the release page <https://github.com/grame-cncm/faust/releases/tag/2.79.3> to download them.
> 

Re: [Faudiostream-devel] [Faudiostream-users] Expression of Interest for the Creation of a Faust Consortium

[yann o. <or...@gm...>]

Thank you, Michel, great! As I was saying to Jeff, the consortium is
intended to bring together legal entities—industries, universities, and
associations—that wish to play a role in shaping the future of Faust,
particularly in defining its roadmap. It also aims to pool financial
resources to ensure the maintenance and development of Faust in the years
to come. Stéphane and I have put together a brochure describing the
project. It's a bit too large for the mailing list, but of course, we can
send it to anyone who is interested.

Le mer. 5 mars 2025 à 08:30, michel buffa <mic...@gm...> a écrit :

> Hi Yann, I'd love to join the consortium.... Will membership be individual
> or at the level of my university or research laboratory? Is there a
> membership fee? How much? Do you need me to commit to any particular tasks?
> If we take as a model the W3C (which is very big), there is the notion of
> “Working Groups (only for members)” and “Community Groups” (open to
> non-members), and there is a decision-making group (the “AB group”), with
> an election system for the latter.
>
> Michel
>
> Le mer. 5 mars 2025 à 03:47, jeff davis <lop...@gm...> a écrit :
>
>> Ok..
>> Is this something I need to join?
>>
>> *Jeff Davis*
>>
>>
>> On Tue, Mar 4, 2025 at 11:17 AM yann orlarey <or...@gm...> wrote:
>>
>>> *(Feel free to share this letter with possible interested industrial
>>> stake-holders or academic partners)*
>>>
>>> Dear Sir or Madam,
>>>
>>> After more than twenty years of research and development led by Grame,
>>> the National Center for Music Creation in Lyon, the Faust programming
>>> language has become a mature and stable software, widely used by an
>>> international community of developers, industry professionals, and academic
>>> researchers, particularly in the field of electronic musical instruments
>>> and audio software. Additionally, Faust is taught at prestigious
>>> universities, further strengthening its academic recognition and global
>>> influence.
>>>
>>> Faust stands out due to several key qualities:
>>>
>>>    - *A high-level language*, designed to express complex digital audio
>>>    processing in a concise and efficient manner.
>>>    - *Advanced compilation techniques and highly efficient code
>>>    generation*, ensuring the transformation of source code into
>>>    high-performance implementations across a wide range of platforms.
>>>    - *A set of libraries composed of specialized DSP building blocks*,
>>>    progressively contributed by the user community, allowing for rapid
>>>    prototyping of sophisticated programs in just a few lines of code.
>>>    - *A rich ecosystem*, enabling the deployment of the same program
>>>    across a wide variety of architectures, from specialized audio boards to
>>>    plugins or standalone applications on computers, all the way to web
>>>    platforms.
>>>
>>> To structure this community and ensure the long-term development of
>>> Faust, we are pleased to present the project for the creation of the Faust
>>> Consortium, managed by *INRIA* <https://inria.fr/en>. This letter aims
>>> to gauge the interest of industrial stakeholders and academic partners in
>>> such a consortium, which would bring together companies, universities, and
>>> organizations wishing to play an active role in the evolution of Faust.
>>>
>>> The Faust Consortium will ensure that Faust remains an open-source
>>> project, accessible to all, while securing its sustainable development and
>>> long-term stability.
>>>
>>> As a member of the Faust Consortium, you will have the opportunity to:
>>>
>>>    - *Participate in strategic decisions*, including defining the
>>>    roadmap for the language and its ecosystem.
>>>    - *Benefit from personalized technical support*, tailored to your
>>>    membership level (Silver, Gold, Platinum).
>>>    - *Contribute to the long-term maintenance* of Faust by pooling
>>>    resources to ensure its sustainable development.
>>>    - *Join a dynamic network of industry, research, and academic
>>>    stakeholders*, fostering synergies and collaborations.
>>>
>>> The Consortium is structured around a General Assembly, responsible for
>>> overall governance, and a Scientific and Technical Committee that defines
>>> and updates the technical roadmap.
>>>
>>> We would be delighted to hear about your interest and that of your
>>> organization in this project and to count you among the future members of
>>> the Faust Consortium. Please feel free to contact us for further
>>> information or to arrange a meeting to discuss the membership details.
>>>
>>> We look forward to your response.
>>>
>>> Sincerely,
>>>
>>> On behalf of the Faust Consortium,
>>> *Yann Orlarey (Inria) <yan...@in...>* and * Stéphane Letz
>>> (Grame) <le...@gr...> *
>>> _______________________________________________
>>> Faudiostream-users mailing list
>>> Fau...@li...
>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>
>> _______________________________________________
>> Faudiostream-users mailing list
>> Fau...@li...
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>

Re: [Faudiostream-devel] [Faudiostream-users] Expression of Interest for the Creation of a Faust Consortium

[yann o. <or...@gm...>]

Hi Jeff,

No, not directly, at least. The consortium is designed to bring together
legal entities such as industries, universities, and associations. Its goal
is to enable them to take part in shaping the future of Faust, particularly
in defining its roadmap. It also aims to pool financial resources to ensure
the maintenance and development of Faust in the years to come. So if you
know of any organizations that might be interested in this initiative, feel
free to share the letter with them.

Best,

Yann

Le mer. 5 mars 2025 à 00:03, jeff davis <lop...@gm...> a écrit :

> Ok..
> Is this something I need to join?
>
> *Jeff Davis*
>
>
> On Tue, Mar 4, 2025 at 11:17 AM yann orlarey <or...@gm...> wrote:
>
>> *(Feel free to share this letter with possible interested industrial
>> stake-holders or academic partners)*
>>
>> Dear Sir or Madam,
>>
>> After more than twenty years of research and development led by Grame,
>> the National Center for Music Creation in Lyon, the Faust programming
>> language has become a mature and stable software, widely used by an
>> international community of developers, industry professionals, and academic
>> researchers, particularly in the field of electronic musical instruments
>> and audio software. Additionally, Faust is taught at prestigious
>> universities, further strengthening its academic recognition and global
>> influence.
>>
>> Faust stands out due to several key qualities:
>>
>>    - *A high-level language*, designed to express complex digital audio
>>    processing in a concise and efficient manner.
>>    - *Advanced compilation techniques and highly efficient code
>>    generation*, ensuring the transformation of source code into
>>    high-performance implementations across a wide range of platforms.
>>    - *A set of libraries composed of specialized DSP building blocks*,
>>    progressively contributed by the user community, allowing for rapid
>>    prototyping of sophisticated programs in just a few lines of code.
>>    - *A rich ecosystem*, enabling the deployment of the same program
>>    across a wide variety of architectures, from specialized audio boards to
>>    plugins or standalone applications on computers, all the way to web
>>    platforms.
>>
>> To structure this community and ensure the long-term development of
>> Faust, we are pleased to present the project for the creation of the Faust
>> Consortium, managed by *INRIA* <https://inria.fr/en>. This letter aims
>> to gauge the interest of industrial stakeholders and academic partners in
>> such a consortium, which would bring together companies, universities, and
>> organizations wishing to play an active role in the evolution of Faust.
>>
>> The Faust Consortium will ensure that Faust remains an open-source
>> project, accessible to all, while securing its sustainable development and
>> long-term stability.
>>
>> As a member of the Faust Consortium, you will have the opportunity to:
>>
>>    - *Participate in strategic decisions*, including defining the
>>    roadmap for the language and its ecosystem.
>>    - *Benefit from personalized technical support*, tailored to your
>>    membership level (Silver, Gold, Platinum).
>>    - *Contribute to the long-term maintenance* of Faust by pooling
>>    resources to ensure its sustainable development.
>>    - *Join a dynamic network of industry, research, and academic
>>    stakeholders*, fostering synergies and collaborations.
>>
>> The Consortium is structured around a General Assembly, responsible for
>> overall governance, and a Scientific and Technical Committee that defines
>> and updates the technical roadmap.
>>
>> We would be delighted to hear about your interest and that of your
>> organization in this project and to count you among the future members of
>> the Faust Consortium. Please feel free to contact us for further
>> information or to arrange a meeting to discuss the membership details.
>>
>> We look forward to your response.
>>
>> Sincerely,
>>
>> On behalf of the Faust Consortium,
>> *Yann Orlarey (Inria) <yan...@in...>* and * Stéphane Letz
>> (Grame) <le...@gr...> *
>> _______________________________________________
>> Faudiostream-users mailing list
>> Fau...@li...
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>

[Faudiostream-devel] Expression of Interest for the Creation of a Faust Consortium

[yann o. <or...@gm...>]

*(Feel free to share this letter with possible interested industrial
stake-holders or academic partners)*

Dear Sir or Madam,

After more than twenty years of research and development led by Grame, the
National Center for Music Creation in Lyon, the Faust programming language
has become a mature and stable software, widely used by an international
community of developers, industry professionals, and academic researchers,
particularly in the field of electronic musical instruments and audio
software. Additionally, Faust is taught at prestigious universities,
further strengthening its academic recognition and global influence.

Faust stands out due to several key qualities:

   - *A high-level language*, designed to express complex digital audio
   processing in a concise and efficient manner.
   - *Advanced compilation techniques and highly efficient code generation*,
   ensuring the transformation of source code into high-performance
   implementations across a wide range of platforms.
   - *A set of libraries composed of specialized DSP building blocks*,
   progressively contributed by the user community, allowing for rapid
   prototyping of sophisticated programs in just a few lines of code.
   - *A rich ecosystem*, enabling the deployment of the same program across
   a wide variety of architectures, from specialized audio boards to plugins
   or standalone applications on computers, all the way to web platforms.

To structure this community and ensure the long-term development of Faust,
we are pleased to present the project for the creation of the Faust
Consortium, managed by *INRIA* <https://inria.fr/en>. This letter aims to
gauge the interest of industrial stakeholders and academic partners in such
a consortium, which would bring together companies, universities, and
organizations wishing to play an active role in the evolution of Faust.

The Faust Consortium will ensure that Faust remains an open-source project,
accessible to all, while securing its sustainable development and long-term
stability.

As a member of the Faust Consortium, you will have the opportunity to:

   - *Participate in strategic decisions*, including defining the roadmap
   for the language and its ecosystem.
   - *Benefit from personalized technical support*, tailored to your
   membership level (Silver, Gold, Platinum).
   - *Contribute to the long-term maintenance* of Faust by pooling
   resources to ensure its sustainable development.
   - *Join a dynamic network of industry, research, and academic
   stakeholders*, fostering synergies and collaborations.

The Consortium is structured around a General Assembly, responsible for
overall governance, and a Scientific and Technical Committee that defines
and updates the technical roadmap.

We would be delighted to hear about your interest and that of your
organization in this project and to count you among the future members of
the Faust Consortium. Please feel free to contact us for further
information or to arrange a meeting to discuss the membership details.

We look forward to your response.

Sincerely,

On behalf of the Faust Consortium,
*Yann Orlarey (Inria) <yan...@in...>* and * Stéphane Letz (Grame)
<le...@gr...> *

Re: [Faudiostream-devel] fb_comb/fb_fcomb implementation

[Oleg N. <ol...@re...>]

Hi Julius,

On 03/02, Julius Smith wrote:
>
> Hi Oleg,
>
> Thanks for the "noise-coefficients test" - I am convinced by that, of
> course, and vote in favor of version 2.

OK, thanks. I have updated

	https://github.com/grame-cncm/faustlibraries/pull/218

Just in case, this is the test-case (included in the changelog of 2/2)

	import("stdfaust.lib");

	// Old implementations before this patch
	o_fb_comb(maxdel,N,b0,aN) = (+ <: de.delay(maxdel,N-1),_) ~ *(-aN) : !,*(b0) : mem;
	o_fb_fcomb(maxdel,N,b0,aN) = (+ <: de.fdelay(maxdel,float(N)-1.0),_) ~ *(-aN) : !,*(b0) : mem;

	maxdel = 10; N = 7.5;

	maxerr = abs : max ~ _;

	test(inp,b0,aN) = inp <:
		fi.fb_comb(maxdel,N,b0,aN)
		-o_fb_comb(maxdel,N,b0,aN),

		fi.fb_fcomb(maxdel,N,b0,aN)
		-o_fb_fcomb(maxdel,N,b0,aN)

		: par(i,2,maxerr);

	process = no.multinoise(3) : test;



> I don't recall if I've said all this before, but my vote is always to
> (1) maintain exact backward compatibility of existing function names,
> (2) address any deviations from references in the doc comments, and
> (3) come up with new function names for new improvements, whatever their
> nature.

Sure, agreed.

Thank you!

Oleg.

Re: [Faudiostream-devel] fb_comb/fb_fcomb implementation

[Julius S. <jul...@gm...>]

Hi Oleg,

Thanks for the "noise-coefficients test" - I am convinced by that, of
course, and vote in favor of version 2.

I don't recall if I've said all this before, but my vote is always to
(1) maintain exact backward compatibility of existing function names,
(2) address any deviations from references in the doc comments, and
(3) come up with new function names for new improvements, whatever their
nature.

Thanks for your pass on all this!

Cheers,
- Julius

Re: [Faudiostream-devel] fb_comb/fb_fcomb implementation

[Oleg N. <ol...@re...>]

On 02/23, Oleg Nesterov wrote:
>
> Julius says:
> >
> > Note that df1 and df2 are _not_ equivalent in the time-varying case
>
> Yes, but I don't see the usage of modulated fb_comb() in *.lib ....
>
> However, I can redo this PR with
>
> 	_fb_comb1(dop,N,b0,aN) = *(aN) + *(b0) ~ dop(N-1);
> 	_fb_comb2(dop,N,b0,aN) = + ~ aN * dop(N-1) : *(b0);
>
> the latter is less efficient, but probably closer to the current implementation
> in the time-varying case.

OK, I verified that with the 2nd version

	_fb_comb(dop,N,b0,aN) = + ~ aN * dop(N-1) : *(b0);

both old and new implementations of fi.fb_comb() output the same in
the time-varying case (b0 == aN == no.noise).

Should I make V2 or should I forget about

	https://github.com/grame-cncm/faustlibraries/pull/218

?

Just in case, fi.fbcombfilter() and fi.ffbcombfilter() (not changed in this PR)
have the same "off by one" error, if "intdel" is compile time constant N, they
implement the following difference equation:

	y[n] = x[n - N] + g * y[n - (N+1)]

and this doesn't match the last equation in

	https://ccrma.stanford.edu/~jos/pasp/Feedback_Comb_Filters.html

Oleg.

Re: [Faudiostream-devel] fb_comb/fb_fcomb implementation

[Oleg N. <ol...@re...>]

Damn!!! sorry for the spam, forgot to mention...

Julius says:
>
> Note that df1 and df2 are _not_ equivalent in the time-varying case

Yes, but I don't see the usage of modulated fb_comb() in *.lib ....

However, I can redo this PR with

	_fb_comb1(dop,N,b0,aN) = *(aN) + *(b0) ~ dop(N-1);
	_fb_comb2(dop,N,b0,aN) = + ~ aN * dop(N-1) : *(b0);

the latter is less efficient, but probably closer to the current implementation
in the time-varying case.

Oleg.

On 02/23, Oleg Nesterov wrote:
>
> Oh...
>
> I am so sorry for the huge delay. Trust me, I was very-very busy with
> my paid work.
>
> Please see https://github.com/grame-cncm/faustlibraries/pull/218
> Hmm... I get the same "Merging is blocked" error again...
>
> I decided to split this change. The second patch is trivial, but the
> changelog is not.
>
> Do you agree with the naming and documentation? If not - I will be happy
> to make V2.
>
> If this PR is accepted, I'll try to do more similar changes (fbcombfilter,
> allpass_comb, and ff_comb).
>
> With or without these changes, IMO the comments above fb_comb/fb_fcomb
> look a bit confusing/inaccurate. But this needs another "doc-only" patch
> and probably not from me ;)
>
> Oleg.
>
>
> On 11/12, Stéphane Letz wrote:
> >
> > Thanks Oleg,
> >
> > Then I can merge a PR, if you can take some time to work on it (with or without the help of Julius, if it make sense.….)
> >
> > Stéphane
> >
> > > Le 12 nov. 2024 à 17:14, Oleg Nesterov <ol...@re...> a écrit :
> > >
> > > Hi Stéphan,
> > >
> > > sorry for the late reply, I was sick.
> > >
> > > On 11/08, Stéphane Letz wrote:
> > >>
> > >> I tried to revive this old question, here is Julius answer.
> > >>
> > >> What do you think here ?
> > >
> > > Well, I still think the same ;) Let me try to summarize, even if I forgot
> > > the details...
> > >
> > > 1. fb_comb/fb_fcomb are suboptimal and can be improved (without changing
> > >   their semantics), this is simple.
> > >
> > > 2. The documentation doesn't match the code. Even if we forget about the
> > >   extra "mem" at the end, the differential equation doesn't match the
> > >   one in https://ccrma.stanford.edu/~jos/pasp/Feedback_Comb_Filters.html
> > >
> > >   I agree with Julius, we should not change the current behaviour, this
> > >   would break (or at least subtly change) the existing code. So I guess
> > >   the documentation should be corrected.
> > >
> > > 3. The new generic helper, something like
> > >
> > > 	_fb_comb(dop,N,b0,aN) = + ~ aN * dop(N-1) : *(b0);
> > >
> > >   makes sense, then we can trivially rewrite fb_comb/fb_fcomb using this
> > >   helper (again, without changing the current behaviour).
> > >
> > >   Plus this helper allows to use, say, dop = de.fdelay4a(max) or any other
> > >   fractional delay.
> > >
> > > And... it's a pity that we're discussing this off-list :/
> > >
> > > Oleg.
> > >
> > >> Stéphane
> > >>
> > >>> Début du message réexpédié :
> > >>>
> > >>> De: Julius Smith <jul...@gm...>
> > >>> Objet: Rép. : fb_comb/fb_fcomb implementation
> > >>> Date: 8 novembre 2024 à 19:42:07 UTC+1
> > >>> À: Stéphane Letz <le...@gr...>
> > >>>
> > >>> Hi Stéphane,
> > >>>
> > >>> Thanks for the forward.  I am not keeping up on Discord!
> > >>> (If there is a way to trigger emails from Discord, please let me know.)
> > >>>
> > >>> I don't recall the details, but things like fb_comb were among the first things I ever wrote in Faust, so I do not expect "hardened code" there.  The trailing MEM was probably to allow use in a feedback loop, as feedback combs started out as Schroeder reverb components.  The case of one versus two delay lines is probably the question of direct form 1 or direct form 2.  I am traveling right now and have limited email time, so if we want to drill down on this, I can do it next week.  In general, I am fine with any and all rewrites, but please use new names when not exactly equivalent!  My favorite MO is when someone writes a whole new suite of primitives with a nice new set of design principles and naming conventions.  To merely exend what I wrote, I would come up with a new name such as fb_comb_df2 for direct-form-2, and also write fb_comb_df1 such that fb_comb == fb_comb_df1 : mem.  Note that df1 and df2 are _not_ equivalent in the time-varying case, and they are very different numerically (which could make a massive difference in a fixed-point version of Faust, should that ever happen, and might impact FPGA implementations now).
> > >>>
> > >>> - Julius
> > >>>
> > >>>
> > >>> On Fri, Nov 8, 2024 at 11:34 AM Stéphane Letz <le...@gr... <mailto:le...@gr...>> wrote:
> > >>> Hi Julius,
> > >>>
> > >>> This old thread came again on Discord : https://sourceforge.net/p/faudiostream/mailman/message/37884756/ <https://sourceforge.net/p/faudiostream/mailman/message/37884756/>
> > >>>
> > >>> What do you think ? Should fb_comb/fb_fcomb  be rewritten with Oleg proposal ?
> > >>>
> > >>> Thanks.
> > >>>
> > >>> Stéphane
> > >>>
> > >>>
> > >>> --
> > >>> For language models, Wittgenstein is right: "The limit of language is the limit of the world"
> > >>
> > >
> >

Re: [Faudiostream-devel] fb_comb/fb_fcomb implementation

[Oleg N. <ol...@re...>]

Oh...

I am so sorry for the huge delay. Trust me, I was very-very busy with
my paid work.

Please see https://github.com/grame-cncm/faustlibraries/pull/218
Hmm... I get the same "Merging is blocked" error again...

I decided to split this change. The second patch is trivial, but the
changelog is not.

Do you agree with the naming and documentation? If not - I will be happy
to make V2.

If this PR is accepted, I'll try to do more similar changes (fbcombfilter,
allpass_comb, and ff_comb).

With or without these changes, IMO the comments above fb_comb/fb_fcomb
look a bit confusing/inaccurate. But this needs another "doc-only" patch
and probably not from me ;)

Oleg.


On 11/12, Stéphane Letz wrote:
>
> Thanks Oleg,
>
> Then I can merge a PR, if you can take some time to work on it (with or without the help of Julius, if it make sense.….)
>
> Stéphane
>
> > Le 12 nov. 2024 à 17:14, Oleg Nesterov <ol...@re...> a écrit :
> >
> > Hi Stéphan,
> >
> > sorry for the late reply, I was sick.
> >
> > On 11/08, Stéphane Letz wrote:
> >>
> >> I tried to revive this old question, here is Julius answer.
> >>
> >> What do you think here ?
> >
> > Well, I still think the same ;) Let me try to summarize, even if I forgot
> > the details...
> >
> > 1. fb_comb/fb_fcomb are suboptimal and can be improved (without changing
> >   their semantics), this is simple.
> >
> > 2. The documentation doesn't match the code. Even if we forget about the
> >   extra "mem" at the end, the differential equation doesn't match the
> >   one in https://ccrma.stanford.edu/~jos/pasp/Feedback_Comb_Filters.html
> >
> >   I agree with Julius, we should not change the current behaviour, this
> >   would break (or at least subtly change) the existing code. So I guess
> >   the documentation should be corrected.
> >
> > 3. The new generic helper, something like
> >
> > 	_fb_comb(dop,N,b0,aN) = + ~ aN * dop(N-1) : *(b0);
> >
> >   makes sense, then we can trivially rewrite fb_comb/fb_fcomb using this
> >   helper (again, without changing the current behaviour).
> >
> >   Plus this helper allows to use, say, dop = de.fdelay4a(max) or any other
> >   fractional delay.
> >
> > And... it's a pity that we're discussing this off-list :/
> >
> > Oleg.
> >
> >> Stéphane
> >>
> >>> Début du message réexpédié :
> >>>
> >>> De: Julius Smith <jul...@gm...>
> >>> Objet: Rép. : fb_comb/fb_fcomb implementation
> >>> Date: 8 novembre 2024 à 19:42:07 UTC+1
> >>> À: Stéphane Letz <le...@gr...>
> >>>
> >>> Hi Stéphane,
> >>>
> >>> Thanks for the forward.  I am not keeping up on Discord!
> >>> (If there is a way to trigger emails from Discord, please let me know.)
> >>>
> >>> I don't recall the details, but things like fb_comb were among the first things I ever wrote in Faust, so I do not expect "hardened code" there.  The trailing MEM was probably to allow use in a feedback loop, as feedback combs started out as Schroeder reverb components.  The case of one versus two delay lines is probably the question of direct form 1 or direct form 2.  I am traveling right now and have limited email time, so if we want to drill down on this, I can do it next week.  In general, I am fine with any and all rewrites, but please use new names when not exactly equivalent!  My favorite MO is when someone writes a whole new suite of primitives with a nice new set of design principles and naming conventions.  To merely exend what I wrote, I would come up with a new name such as fb_comb_df2 for direct-form-2, and also write fb_comb_df1 such that fb_comb == fb_comb_df1 : mem.  Note that df1 and df2 are _not_ equivalent in the time-varying case, and they are very different numerically (which could make a massive difference in a fixed-point version of Faust, should that ever happen, and might impact FPGA implementations now).
> >>>
> >>> - Julius
> >>>
> >>>
> >>> On Fri, Nov 8, 2024 at 11:34 AM Stéphane Letz <le...@gr... <mailto:le...@gr...>> wrote:
> >>> Hi Julius,
> >>>
> >>> This old thread came again on Discord : https://sourceforge.net/p/faudiostream/mailman/message/37884756/ <https://sourceforge.net/p/faudiostream/mailman/message/37884756/>
> >>>
> >>> What do you think ? Should fb_comb/fb_fcomb  be rewritten with Oleg proposal ?
> >>>
> >>> Thanks.
> >>>
> >>> Stéphane
> >>>
> >>>
> >>> --
> >>> For language models, Wittgenstein is right: "The limit of language is the limit of the world"
> >>
> >
>

[Faudiostream-devel] New ondemand primitive to test

[Stéphane L. <le...@gr...>]

Hi people,

The new ondemand primitive (announced by Yann Orlarey during the International Faust Conference 2024, see latest section ”The Future of Faust” here: https://www.youtube.com/watch?v=zli5sFc5dlE) can be tested in the Work In Progress branch here on the Faust GitHub: https://github.com/grame-cncm/faust/tree/master-dev-ocpp-od-fir-2-FIR. Note that the produced code may be slower compared to the official compiler since all delay-line related optimisations are not yet reported in this new version.

The corresponding WebAssembly version is compiled in this Faust IDE version: https://grame-cncm.github.io/faustide-od/. Three ondemand examples can be tested in the included examples/ondemand folder (see ondemand.dsp, bubble.dsp, gamme.dsp). Note that the remote compilation service (so when using the export button) is not yet using the ondemand aware compiler. 

We are interested in feedback: possibly crashing DSP or any specific problem you may encounter.

Stéphane 

[Faudiostream-devel] Faust pre-release 2.77.3

[github-actions[bot] <le...@gr...>]

Faust version 2.77.3 <https://github.com/grame-cncm/faust/releases/tag/2.77.3>
Repository: grame-cncm/faust <https://github.com/grame-cncm/faust> · Tag: 2.77.3 <https://github.com/grame-cncm/faust/tree/2.77.3> · Commit: c7ec4c2 <https://github.com/grame-cncm/faust/commit/c7ec4c20171013d3266425a07e7723bf44b790c2> · Released by: github-actions[bot] <https://github.com/apps/github-actions>
Change log

WARNING: to get the source version

be sure to download the faust-2.77.3.tar.gz file to get a complete source folder (in particular, with all the libraries)
on macOS, binary files are still to notarise, you may have to use the xattr -rd com.apple.quarantine file command to remove the com.apple.quarantine extended attribute. See the xattr man page <https://developer.apple.com/documentation/os/reading_unix_manual_pages> for details on how to use that tool. MacOS Monterey is now the minimal version.
New

Remove undeeded SVG generation in faustgen.
Add -miniaudio option to faust2api.
MiniaudioReader and miniaudio device using miniaudio library.
Compilation is now deterministic.
Add lint test for nondeterministic pointer comparison
Add signal interpreter (WIP).
Rust: provide a inplace interface for rust
Implement soundfile handling at init stage in C, C++, LLVM and Interp backends.
Add the 'varname' field to the JSON format.
Update MIR backend for 1.0.0 API.
Implement -ec, -cm and -os options in Rust backend.
Rework minimal.c to demonstrate use of UIGlue.
Updated class daisy_midi to be compatible with libDaisy v7.1.0
Implement SDF3 generation backend.
Rework Rust code generation.
Use shortnames instead of labels in Cmajor backend.
Add Faust DSP Testbench in JUCE architecture.
Deprecated

Fixed bugs

Remove empty groups when merging UI subcontainers.
Fix duplicated bar graphs bug caused by double simplification.
Fix missing type annotation step. This step is needed to draw the retimed sig graph.
Reserved keyword used in labels do not trigger impossible simplications anymore.
uiCheckButton in JuceGUI state handling.
Correct -fgpa-mem option handing combined with fDLThreshold.
Add -universal option in faust2unity, formatting.
Update fastmath.cpp to be used with a C compiler.
Update fastmath.cpp for GCC >= 14.2.x.
Add a cmake LINK_LLVM_STATIC option.
Add :: prefix to dsp class to help with integration in JUCE.
Libraries

Add oneEuro filter.
Add ba.mulaw_bitcrusher function.
Add Kalman filter.
Add linear algebra library.
Topology-preserving transform SVF following Zavalishin's method; Andy Simper's Dynamic Smoothing.
Add ba.tAndH and fix ma.zc.
Add second-order anti-aliased softclip.
aa.softclipQuadratic2 renamed in aa.softclipQuadratic1.
Add anti-aliased quadratic softclip.
Add linear piecewise interpolation function.

[Faudiostream-devel] Join the International Faust Conference 2024 - November 21-22 in Turin

[Stéphane L. <le...@gr...>]

> 
> FREE EVENT! 
>  	
>  <>
>  <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830ca>
> 
> Dear Stéphane,
> We’re excited to invite you to the International Faust Conference 2024 (IFC24), a two-day scientific event dedicated to Faust, the powerful functional programming language for real-time audio signal processing and synthesis.
> This year’s edition will take place in Turin, Italy, at Toolbox Co-working <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830cc> on November 21-22, 2024 and is organized by SOUNDMIT <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830ce>, GRAME <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830d0>, INRIA <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830d2>
> What to expect:
> Keynote presentations by researchers, developers and industry experts
> Technical workshops
> Live demonstrations
> Interactive sessions on the latest advancements in audio programming
> IFC24 is a unique opportunity for researchers, developers, educators, and audio enthusiasts to explore Faust, learn innovative programming techniques, and connect with experts from around the world.
> 
> Read the complete schedule, CLICK HERE <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830d4>!
> 
> The event is free to attend, but registration is required by emailing  <>if...@so... <mailto:if...@so...> before 20 November. You can also join the conference via live streaming on the official YouTube channel: Soundmit YouTube Channel <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830d6>.
> 
> Join us for two days of inspiration, learning, and networking in the vibrant city of Turin!
> 
> Soundmit
>    
> We have changed our email newsletter providers, and we are now using a service that we truly believe in. We apologize if, during this transition phase, you received duplicate emails or missed our previous communications.
>    
>  <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830d8>
> Facebook
>  <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830da>	
>  <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830dc>
> Youtube
>  <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830de>	
>  <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830e0>
> Instagram
>  <https://vtyb-zcmp.maillist-manage.eu/click/1233bdb5b488535f/1233bdb5b48830e2>	
>  <mailto:in...@so...>
> Email
>  <mailto:in...@so...>
> Our mailing address is:
> Want to change how you receive these emails?
> you can update your preferences <https://vtyb-zcmp.maillist-manage.eu/ua/upc?upd=1233bdb5b4882ed2&r=1233bdb5b488535f&n=11699e4bf50806c&od=3z707bff4cfa59c03e7af24b5b152b7889> or unsubscribe from this list. <https://vtyb-zcmp.maillist-manage.eu/ua/optout?od=3z707bff4cfa59c03e7af24b5b152b7889&rd=1233bdb5b488535f&sd=1233bdb5b4883379&n=11699e4bf50806c>
>  

Re: [Faudiostream-devel] fb_comb/fb_fcomb implementation

[Stéphane L. <le...@gr...>]

> -------------------------------------------------------------------
> Meanwhile. Can you look at
> 
> 	https://github.com/grame-cncm/faustlibraries/pull/172
> 
> ? this was discussed on
> https://sourceforge.net/p/faudiostream/mailman/faudiostream-users/
> and (iirc) this change was acked by Dario (you were cc'ed). Yet it
> was silently ignored.
> 
> Not a big deal, and in fact I was going to close this PR because
> nobody was interested, but still... I simply can't understand what
> should/can I do if I make the PR and nobody reacts.
> 
> Just in case. github.com reports the conficts in maths.lib, but
> this is only because ee0d14ae571d82aaa10209e5c6eb51550450f235
> ("add ma.primes") was merged after my PR was ignored.
> 
> Oleg.
> 

Merged, thanks.

Stéphane 

Re: [Faudiostream-devel] fb_comb/fb_fcomb implementation

[Oleg N. <ol...@re...>]

On 11/12, Stéphane Letz wrote:
>
> Thanks Oleg,
>
> Then I can merge a PR, if you can take some time to work on it
> (with or without the help of Julius, if it make sense.….)

Oh. I'll try to do this. Maybe next month, currently I am very-very
busy with my paid work which has nothing to do with dsp/faust/etc.

1. is trivial, I can make a PR.

But as for 2. and 3. Technically simple, but I don't know how to
fix the current documentation or write the new one for the new helper.

I will try.

-------------------------------------------------------------------
Meanwhile. Can you look at

	https://github.com/grame-cncm/faustlibraries/pull/172

? this was discussed on
https://sourceforge.net/p/faudiostream/mailman/faudiostream-users/
and (iirc) this change was acked by Dario (you were cc'ed). Yet it
was silently ignored.

Not a big deal, and in fact I was going to close this PR because
nobody was interested, but still... I simply can't understand what
should/can I do if I make the PR and nobody reacts.

Just in case. github.com reports the conficts in maths.lib, but
this is only because ee0d14ae571d82aaa10209e5c6eb51550450f235
("add ma.primes") was merged after my PR was ignored.

Oleg.

> Stéphane
>
> > Le 12 nov. 2024 à 17:14, Oleg Nesterov <ol...@re...> a écrit :
> >
> > Hi Stéphan,
> >
> > sorry for the late reply, I was sick.
> >
> > On 11/08, Stéphane Letz wrote:
> >>
> >> I tried to revive this old question, here is Julius answer.
> >>
> >> What do you think here ?
> >
> > Well, I still think the same ;) Let me try to summarize, even if I forgot
> > the details...
> >
> > 1. fb_comb/fb_fcomb are suboptimal and can be improved (without changing
> >   their semantics), this is simple.
> >
> > 2. The documentation doesn't match the code. Even if we forget about the
> >   extra "mem" at the end, the differential equation doesn't match the
> >   one in https://ccrma.stanford.edu/~jos/pasp/Feedback_Comb_Filters.html
> >
> >   I agree with Julius, we should not change the current behaviour, this
> >   would break (or at least subtly change) the existing code. So I guess
> >   the documentation should be corrected.
> >
> > 3. The new generic helper, something like
> >
> > 	_fb_comb(dop,N,b0,aN) = + ~ aN * dop(N-1) : *(b0);
> >
> >   makes sense, then we can trivially rewrite fb_comb/fb_fcomb using this
> >   helper (again, without changing the current behaviour).
> >
> >   Plus this helper allows to use, say, dop = de.fdelay4a(max) or any other
> >   fractional delay.
> >
> > And... it's a pity that we're discussing this off-list :/
> >
> > Oleg.
> >
> >> Stéphane
> >>
> >>> Début du message réexpédié :
> >>>
> >>> De: Julius Smith <jul...@gm...>
> >>> Objet: Rép. : fb_comb/fb_fcomb implementation
> >>> Date: 8 novembre 2024 à 19:42:07 UTC+1
> >>> À: Stéphane Letz <le...@gr...>
> >>>
> >>> Hi Stéphane,
> >>>
> >>> Thanks for the forward.  I am not keeping up on Discord!
> >>> (If there is a way to trigger emails from Discord, please let me know.)
> >>>
> >>> I don't recall the details, but things like fb_comb were among the first things I ever wrote in Faust, so I do not expect "hardened code" there.  The trailing MEM was probably to allow use in a feedback loop, as feedback combs started out as Schroeder reverb components.  The case of one versus two delay lines is probably the question of direct form 1 or direct form 2.  I am traveling right now and have limited email time, so if we want to drill down on this, I can do it next week.  In general, I am fine with any and all rewrites, but please use new names when not exactly equivalent!  My favorite MO is when someone writes a whole new suite of primitives with a nice new set of design principles and naming conventions.  To merely exend what I wrote, I would come up with a new name such as fb_comb_df2 for direct-form-2, and also write fb_comb_df1 such that fb_comb == fb_comb_df1 : mem.  Note that df1 and df2 are _not_ equivalent in the time-varying case, and they are very different numerically (which could make a massive difference in a fixed-point version of Faust, should that ever happen, and might impact FPGA implementations now).
> >>>
> >>> - Julius
> >>>
> >>>
> >>> On Fri, Nov 8, 2024 at 11:34 AM Stéphane Letz <le...@gr... <mailto:le...@gr...>> wrote:
> >>> Hi Julius,
> >>>
> >>> This old thread came again on Discord : https://sourceforge.net/p/faudiostream/mailman/message/37884756/ <https://sourceforge.net/p/faudiostream/mailman/message/37884756/>
> >>>
> >>> What do you think ? Should fb_comb/fb_fcomb  be rewritten with Oleg proposal ?
> >>>
> >>> Thanks.
> >>>
> >>> Stéphane
> >>>
> >>>
> >>> --
> >>> For language models, Wittgenstein is right: "The limit of language is the limit of the world"
> >>
> >
>

Re: [Faudiostream-devel] fb_comb/fb_fcomb implementation

[Stéphane L. <le...@gr...>]

Thanks Oleg,

Then I can merge a PR, if you can take some time to work on it (with or without the help of Julius, if it make sense.….)

Stéphane 

> Le 12 nov. 2024 à 17:14, Oleg Nesterov <ol...@re...> a écrit :
> 
> Hi Stéphan,
> 
> sorry for the late reply, I was sick.
> 
> On 11/08, Stéphane Letz wrote:
>> 
>> I tried to revive this old question, here is Julius answer.
>> 
>> What do you think here ?
> 
> Well, I still think the same ;) Let me try to summarize, even if I forgot
> the details...
> 
> 1. fb_comb/fb_fcomb are suboptimal and can be improved (without changing
>   their semantics), this is simple.
> 
> 2. The documentation doesn't match the code. Even if we forget about the
>   extra "mem" at the end, the differential equation doesn't match the
>   one in https://ccrma.stanford.edu/~jos/pasp/Feedback_Comb_Filters.html
> 
>   I agree with Julius, we should not change the current behaviour, this
>   would break (or at least subtly change) the existing code. So I guess
>   the documentation should be corrected.
> 
> 3. The new generic helper, something like
> 
> 	_fb_comb(dop,N,b0,aN) = + ~ aN * dop(N-1) : *(b0);
> 
>   makes sense, then we can trivially rewrite fb_comb/fb_fcomb using this
>   helper (again, without changing the current behaviour).
> 
>   Plus this helper allows to use, say, dop = de.fdelay4a(max) or any other
>   fractional delay.
> 
> And... it's a pity that we're discussing this off-list :/
> 
> Oleg.
> 
>> Stéphane
>> 
>>> Début du message réexpédié :
>>> 
>>> De: Julius Smith <jul...@gm...>
>>> Objet: Rép. : fb_comb/fb_fcomb implementation
>>> Date: 8 novembre 2024 à 19:42:07 UTC+1
>>> À: Stéphane Letz <le...@gr...>
>>> 
>>> Hi Stéphane,
>>> 
>>> Thanks for the forward.  I am not keeping up on Discord!
>>> (If there is a way to trigger emails from Discord, please let me know.)
>>> 
>>> I don't recall the details, but things like fb_comb were among the first things I ever wrote in Faust, so I do not expect "hardened code" there.  The trailing MEM was probably to allow use in a feedback loop, as feedback combs started out as Schroeder reverb components.  The case of one versus two delay lines is probably the question of direct form 1 or direct form 2.  I am traveling right now and have limited email time, so if we want to drill down on this, I can do it next week.  In general, I am fine with any and all rewrites, but please use new names when not exactly equivalent!  My favorite MO is when someone writes a whole new suite of primitives with a nice new set of design principles and naming conventions.  To merely exend what I wrote, I would come up with a new name such as fb_comb_df2 for direct-form-2, and also write fb_comb_df1 such that fb_comb == fb_comb_df1 : mem.  Note that df1 and df2 are _not_ equivalent in the time-varying case, and they are very different numerically (which could make a massive difference in a fixed-point version of Faust, should that ever happen, and might impact FPGA implementations now).
>>> 
>>> - Julius
>>> 
>>> 
>>> On Fri, Nov 8, 2024 at 11:34 AM Stéphane Letz <le...@gr... <mailto:le...@gr...>> wrote:
>>> Hi Julius,
>>> 
>>> This old thread came again on Discord : https://sourceforge.net/p/faudiostream/mailman/message/37884756/ <https://sourceforge.net/p/faudiostream/mailman/message/37884756/>
>>> 
>>> What do you think ? Should fb_comb/fb_fcomb  be rewritten with Oleg proposal ?
>>> 
>>> Thanks.
>>> 
>>> Stéphane
>>> 
>>> 
>>> --
>>> For language models, Wittgenstein is right: "The limit of language is the limit of the world"
>> 
> 

[Faudiostream-devel] Faust version 2.75.7 pre-release to test

[Stéphane L. <le...@gr...>]

Here: https://github.com/grame-cncm/faust/releases/tag/2.75.7

Feedback in case of issues welcome. 

Stéphane 

[Faudiostream-devel] International Faust Conference 2024 (IFC-24), Turin (Italy), Nov. 21-22, 2024

[Stéphane L. <le...@gr...>]

Hi everyone,

Just a friendly reminder that the deadline for submitting a paper to the 2024 International Faust Conference (IFC-24) is July 12th, 2024 ;), see https://ifc24.soundmit.com/en

Best,

Stéphane 

[Faudiostream-devel] Faust 2.74.6 prerelease to test

[Stéphane L. <le...@gr...>]

Here: https://github.com/grame-cncm/faust/releases/tag/2.74.6

Feedback welcome !

Stéphane

[Faudiostream-devel] The soundfile primitive can finally be used in the Faust Web IDE

[Stéphane L. <le...@gr...>]

The soundfile primitive can finally be used in the Faust Web IDE (WIP), see: https://github.com/grame-cncm/faustide?tab=readme-ov-file#soundfiles-access

Stéphane 

[Faudiostream-devel] FaustLive version 2.5.18 released

[Stéphane L. <le...@gr...>]

https://github.com/grame-cncm/faustlive/releases/tag/2.5.18

Stéphane 

[Faudiostream-devel] Faust version 2.72.14 released

[Stéphane L. <le...@gr...>]

https://github.com/grame-cncm/faust/releases/tag/2.72.14

Stéphane

[Faudiostream-devel] Faust version 2.72.13 pre-release version to test

[Stéphane L. <le...@gr...>]

https://github.com/grame-cncm/faust/releases/tag/2.72.13

Stéphane 

[Faudiostream-devel] Faust Conference (IFC) 2024 in Turin, Italy, on November 21-22, 2024.

[Stéphane L. <le...@gr...>]

Soundmit announces that it will host the International Faust Conference (IFC) 2024 in Turin, Italy, on November 21-22, 2024. The IFC is a biennial event that brings together the global community of developers and users of the FAUST audio programming language. The conference offers a unique opportunity to: 

Learn more about the FAUST language and its various applications Meet other professionals in the audio and music industry Attend talks, workshops, and panels on a variety of topics related to FAUST Contribute to the future development of the language The IFC 2024 will be held two days before the 14th edition of Soundmit, the international fair on synthesizers, electronic musical instruments, digital music and sound art, which will take place in Turin on November 23-24, 2024. The two events will be united for the first time, creating a unique opportunity for participants to fully immerse themselves in the world of digital audio. 

Companies that wish to support the conference can do so with a small sponsorship that offers a great return in terms of visibility. It is also possible to participate in the Soundmit as an exhibitor to present your products and services to an international audience of professionals. 

 Dates: IFC24 - 21/22 Nov 2024 - Turin 
SOUNDMIT (14th edition) - 23/24 Nov 2024 - Turin 

https://www.soundmit.com/en
https://ifc24.soundmit.com/en