[back on mailing list] Ha, I don't think any question regarding tagging and filtering counts as "simplistic"! Good luck.
On Fri, Nov 20, 2020 at 10:04 AM Nicholas Long <nicholaslon...@gmail.com> wrote: > Yes, what you described in the first section is what I am planning, > > Looking at it more, my main concern was ensuring that the full data block > of taps was on the output block at of whatever is feeding the tapped input > to my OOT module, though I am realizing now that that is a problem for the > output block, and can be easily solved by putting a check on the tap > generator block like is in tagged_stream_block.cc and use > set_min_noutput_items. > > Thanks for the quick response, and sorry for the simplistic question. > Have a great day. > > > > On Fri, Nov 20, 2020 at 8:22 AM Jeff Long <willco...@gmail.com> wrote: > >> If the taps need to be changed exactly at the tag, then I think you'll >> have to make your own version of the filter block you're using, adding >> handling for a "set_taps" tag. None of the filter blocks pay any attention >> to tags and a call to set_taps() would take effect "approximately" when you >> mean it to. >> >> If the taps need to change at approximately the time of the tag, then you >> could just either (1) forget about tags and drive the changes from your >> Python program, or (2) make a block (e.g., Python Embedded) that just looks >> for tags in the stream and calls set_taps() on your filter. >> >> On Fri, Nov 20, 2020 at 8:38 AM Nicholas Long <nicholaslon...@gmail.com> >> wrote: >> >>> Hi, I am looking for comments/thoughts/advice on how to combine (fan in) >>> untagged and tagged streams. >>> >>> Basically my goal is to make a sample synchronous filter with adjustable >>> taps, where the data to be filtered is a untagged stream that periodically >>> has a tag flag saying "update taps" when this flag is seen the block will >>> look at the other input (tagged) and use the next pdu block there as the >>> taps for the newly configured filter. I do not want to define the filter >>> length before runtime, and that as the number of filter taps can change >>> between update calls. Also because there is no packet type structure It >>> does not make sense for the data stream to be tagged (though that is my >>> current fallback plan). >>> >>> Thanks, >>> Nick >>> >>
