On Mon, Nov 19, 2012 at 2:40 PM, Tom Rondeau <[email protected]> wrote: > On Mon, Nov 19, 2012 at 1:57 PM, Johnathan Corgan > <[email protected]> wrote: >> On Mon, Nov 19, 2012 at 9:22 AM, Ed Criscuolo <[email protected]> >> wrote: >> >>> >>> I agree that changing the way gr_iir_filter takes in the taps could >>> be disruptive, unless backward compatibility is maintained. Some of >>> the group are using GnuRadio for operational systems. >> >> >> Yes. >> >>> >>> Here's two more suggestions for solutions: >>> >>> 1. Add an optional flag parameter to the constructor, with values >>> of "Old_API" and "New_API", with the default set to "Old_API". >>> This flag would control how gr_iif_filter interprets the taps. >>> It could be maintained this way for some time, with the Old_API >>> being deprecated, and eventually change the default to >>> New_API, or even make the default a cmake option. >>> >>> 2. Create two subclasses of filter taps that are identical in >>> format, and use C++ overloading to determine which constructor >>> or set method to use. >> >> >> I think the first is most straightfoward and consistent with how we've make >> API changes in the past. >> >> Johnathan > > Agreed. That's a pretty sane way of helping make the transition. An > argument to the constructor should make people perk up and pay > attention to the fact that there is a change. > > Tom
I just pushed a branch to my github repo called iir_filter that implements the optional argument to the IIR filter as we discussed. The default is oldstyle=True and doesn't change any behavior. If you set this to False, you can directly copy taps from programs like gr_filter_design (the new version not yet integrated into GNU Radio). Comments, questions, etc.? If no one sees a problem with this, I'll merge it into next. Tom _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
