On 11/19/12 10:11 AM, Tom Rondeau wrote:
used? Should be change the way gr_iif_filter takes in the taps, or
should we change how gr_filter_design produces them?
Thanks for the feedback!
Tom
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.
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.
@(^.^)@ Ed
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
