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 <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
