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 <o...@redhat.com> 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 <julius.sm...@gmail.com> >>> Objet: Rép. : fb_comb/fb_fcomb implementation >>> Date: 8 novembre 2024 à 19:42:07 UTC+1 >>> À: Stéphane Letz <l...@grame.fr> >>> >>> 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 <l...@grame.fr >>> <mailto:l...@grame.fr>> 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 mailing list Faudiostream-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
